TanStack 作者：借助 AI，我们将迎来软件的“Linux 发行版”时代 —— 记重塑 React 的一次实验

原文标题： Projecting React 原文作者： Tanner Linsley (TanStack 作者) 原文链接： https://tannerlinsley.com/posts/projecting-react 译者导读： Tanner 的这次实验，是对当前 AI 落地能力的一次完美展示。作为开发者，我们在优化基础设施或者追求极致性能（例如剔除系统冗余、压榨毫秒级延迟）时，往往受限于高昂的“重写成本”，只能被迫接受上游庞大的“通用全家桶”。 但 @tanstack/redact 的诞生证明了，借助 AI 获得一个高度裁剪、完美贴合业务“形状”的专属运行时，已经触手可及。结合目前社区里越来越活跃的本地 AI Agent 框架生态（例如 QClaw 等隐私友好的本地化自动化工具），当 Agent 能与我们的日常工作流深度结合时，“代码投影”的门槛将进一步降低。未来，“官方提供核心协议 + 本地 Agent 自动化按需编译/裁剪” 或许会成为我们提升数字生产力的标准范式。

💡 核心观点速览 (TL;DR)

• 技术痛点： React 的包体积过于庞大（约 60KB gzip），对于只需部分核心功能的框架（如 TanStack Start）来说，造成了严重的冗余。
• 范式转变： 在 AI 时代，代码正在从“权威产物”变成一种“物化视图（Materialized View）”。由于 AI 极大地降低了重写代码的成本，核心的 API 契约（思想）成为了真正的 Source of Truth，而具体的代码实现只是这些思想的其中一种“投影（Projection）”。
• 硬核实践： 作者借助 AI，仅花一天时间就根据 React 19 的公共 API 规范，编写了一个名为 @tanstack/redact 的最小化、可裁剪的 React 运行时投影。它体积仅为 7-9 KB，性能大幅提升，且完全兼容所需的 React 生态。
• 未来趋势： 未来的开源软件会像 Linux 一样——官方代码库只是“内核”，而开发者借助 AI，可以根据自身业务的特定“形状”，低成本地定制出属于自己的“发行版”。

1. 缘起：React 太重了，而 Preact 已经不再是完美的平替

Tanner 在开发 TanStack Start 时遇到了一个令人头疼的阻力：React 实在太大了。经过 Vite 打包后，客户端加载的 React 体积依然高达 ~60 KB（gzip）。相比之下，TanStack 生态的其他工具（Router, Query, Store 等）加起来也就是个零头。在一个技术栈中，你最无法移除的基础组件，居然也是体积最大的组件，这很不合理。

常规思路是换用 Preact（preact/compat）。但这在 React 19 时代已经行不通了。Preact 的兼容层与 React 19 出现了不小的分歧（涉及 use() 语义、Server Actions、Portals、Hydration 边缘情况等），修复这些问题变成了“在补丁上打补丁”。

根本问题不在于 Preact，而在于：Tanner 需要的是 React 公共 API 在一个更小作用域下的精确“投影”。

2. 认知升级：代码只是“物化视图 (Materialized View)”

Gatsby 的作者 Kyle Mathews 提出了一个深刻的观点，促成了这次实验：

“编程智能体（AI Agent）将代码从‘最终产物’变成了‘物化视图’。底层的数据表是思想（算法、协议、语义契约），而代码只是其中一种投影。过去几十年，我们把代码本身当作权威，是因为重新生成代码的成本太高。但现在时代变了。”

一旦重写代码的成本无限趋近于零，模型就反转了。React 的公共 API 才是那张“底层数据表”（包括元素模型、Hooks 契约、Suspense 语义、SSR 流式传输协议等），而 Facebook 官方维护的 React 代码库，只是基于这个 API 的其中一种投影（它包含了时间切片、并发模式、DevTools 等 TanStack Start 根本用不到的沉重逻辑）。

3. 破局之道：@tanstack/redact 的诞生

如果成本极低，为什么不让 AI 根据 TanStack Start 的特定需求，生成一个专属的“React 投影”呢？这就是 @tanstack/redact。

它的核心架构设计如下：

• 精简的底层（7.08 KB）： 包含 Fiber 协调器、DOM 挂载/更新、标准 Hooks（useState, useEffect 等）、事件绑定和 JSX 运行时。
• 8 个可插拔的功能模块： Context、Suspense、Memo、Lazy、Hydration 等功能全部被设计为可按需开启。
• 绝对的定制化： 彻底砍掉了并发渲染、时间切片、调度器和 React DevTools，因为这些属于 TanStack Start 场景下不需要的“产品决策”。所有的过渡降级为同步执行。

利用 Vite 插件，如果在配置中关掉某个特性，它就会被替换为极简的存根，真实的复杂代码根本不会进入打包模块树。开发者只需从 @tanstack/redact/vite 导入 redact 函数并进行配置即可：

传入参数 preset 设为 full，可获得约 9.39 KB 的完整 React 投影，开发者可以手动剔除不需要的模块；若将 preset 设为 nano，则可获得约 7.08 KB 的最小核心，开发者只需按需开启额外需要的模块。

最令人惊叹的是，RSC（React Server Components）依然可以完美运行。这个投影直接复用了官方真实的 react-server-dom 包，仅仅是替换了底层的 React 运行时。

4. 实战表现：一天构建，性能飙升

借助 Claude，这个定制过程只花了一天的提示词工程时间。AI 已经掌握了如何实现这些逻辑，它只需要你告诉它“做哪一种裁剪”。

随后的工作并不是写代码，而是“排雷”。Tanner 将自己的博客和 TanStack 官网（包含大量复杂的 Router、RSC 和交互组件）无缝迁移到了这个方案上。在真实的生产流量下，暴露出了一些协调器顺序、Effect 清理时机等深层 BUG——而这也是它区别于“粗制滥造分支”的地方，它的报错模式和官方 React 是一致的。

收益极其惊人（对标 React 19.2.3）：

• 体积： 减小了 80%–85%。在全规模的复杂应用中，直接砍掉了将近 1MB 的客户端 JS。
• 性能： 因为没有了复杂的调度器和 Fiber 循环，客户端路由导航快了 2.24 倍，SSR 吞吐量提升了约 3 倍。
• 核心体验指标： LCP、FCP 在移动端有显著提升，且完全没有功能回退。

5. 展望：“不进行投影定制，才是对产品的不负责任”

在此之前，Cloudflare 的工程师也用 AI 花了一周时间重写了 Next.js 的 API 表面（即 vinext），虽然被戏称为带有商业目的的分支，但本质上它也是一种投影。

Tanner 认为：

如果你不再需要官方库为了兼顾所有人而塞入的“通用管道”，且现在定制剪裁的成本只需一个周末（而不是几个月），那么盲目引入庞大且包含大量无用代码的官方全量包，本身就是一种需要承担后果的决策。

未来的软件开发，会越来越像 Linux 发行版或音乐的混音版：

没有绝对的“正统代码”。上游提供的是坚如磐石的“核心理念和 API 规范”，而开发者将利用 AI 根据自己真实的业务需求，快速投影出高度定制化的运行时。

注：Tanner 明确表示 @tanstack/redact 只是一个个人实验，不会作为 TanStack 的官方依赖强推给社区。但它证明了一点：在 AI 的加持下，“使用上游默认版本”已经不再是我们唯一的、理所当然的选择了。