React Compiler 从 TypeScript 搬到 Rust：一次 AI 主导的重写实验

预计阅读时间：9 分钟

React 团队刚在 GitHub 上合并了一个引发大量讨论的 PR——把 React Compiler 的核心实现从 TypeScript 移植到 Rust。提交者是核心团队成员 Joseph Savona，他给这个实验性项目贴了一个更惹眼的标签：AI 主导编码、人类紧密指导。

这意味着两件事：React 的编译优化工具正在换一条更快的引擎；而这条引擎的建造方式本身，也值得每个工程团队停下来看一眼。

React Compiler 到底在做什么

先回到工具本身。React Compiler 不是另一个打包器或转译器，它的职责很窄但很硬：自动分析组件代码，插入 memoization，消除不必要的重渲染。

手动优化时，开发者要写 useMemo、useCallback、React.memo，判断哪个值该缓存、哪个函数该稳定。这套判断容易出错——漏写一个 memo 就拖慢整条渲染链，过度 memo 又增加内存和代码复杂度。React Compiler 用静态分析替你做这些决定。

一段没有手动优化的组件：

function ProductList({ products, filterText }) {
  const filtered = products.filter(p => p.name.includes(filterText));
  const sorted = filtered.sort((a, b) => a.price - b.price);

  return (
    <ul>
      {sorted.map(p => <ProductCard key={p.id} product={p} />)}
    </ul>
  );
}

每次 filterText 变化，filtered 和 sorted 都会重新计算——这没问题。但如果父组件的其他 state 变了（跟 filterText 无关），这两个值也会被重新创建，触发 ProductCard 全量重渲染。

手动加 memo 是这样：

function ProductList({ products, filterText }) {
  const filtered = useMemo(
    () => products.filter(p => p.name.includes(filterText)),
    [products, filterText]
  );
  const sorted = useMemo(
    () => filtered.sort((a, b) => a.price - b.price),
    [filtered]
  );

  return (
    <ul>
      {sorted.map(p => (
        <React.memo(ProductCard) key={p.id} product={p} />
      ))}
    </ul>
  );
}

启用 React Compiler 后，你写第一版代码（没有任何 memo），编译器自动输出等价于第二版的优化结果。开发者不再需要手动判断缓存边界。

为什么搬去 Rust

TypeScript 写编译器有一个天然优势：和 React 生态同语言，调试、测试、发布都方便。React Compiler 最初的实现就是纯 TypeScript，跑在 Node 端，作为 Babel 插件或 Vite 插件集成到构建流程。

但 TypeScript 有两个结构性短板：

运行时性能。大型项目（数千组件）的编译耗时会显著拉长。TypeScript 编译器本身是单线程、解释执行的，做深度 AST 分析和多次遍历时吞吐量受限。
并行与内存控制。Rust 的所有权模型让并行分析天然安全，不需要 GC 暂停，内存占用更可控。对于需要处理整棵组件树的全局优化，这是关键优势。

Rust 在编译工具链领域的渗透已经不是新闻——SWC、Turbopack、Deno 的核心模块都用 Rust 重写。React Compiler 加入这个行列，逻辑上顺理成章。

"AI 主导编码、人类紧密指导"——开发模式本身才是实验

Joseph Savona 在 PR 描述中明确说，这次移植的核心代码大量由 AI 生成，他自己扮演的角色是架构决策者、方向校准者和质量把关人。

这不是"让 AI 写点辅助代码"的轻度使用，而是把编码主体交给 AI，人类做高密度的方向干预：

决定模块边界和数据流走向
在 AI 产出偏差时及时纠正路径
审查每一批生成代码的类型安全和语义正确性

这种模式能跑通，前提是人对目标领域有极深的理解。Savona 是 React Compiler 的原作者，TypeScript 版的每一行他都写过或审查过。他知道哪些逻辑必须保留、哪些可以重构、Rust 侧的等价表达应该是什么形态。AI 在这里替代的是"把已知逻辑翻译到新语言"的机械劳动，而不是"设计新逻辑"的创造性工作。

对普通团队的启示：AI 主导编码不是让新手指挥 AI，而是让专家把重复性翻译工作外包出去。如果你对目标领域不够熟，AI 生成的代码你连审都审不了。

实际影响与注意事项

对项目构建的影响

React Compiler 的 Rust 版目前是实验性合并，不会立刻替换 TypeScript 版。两个实现会并行存在一段时间。对已经在用 React Compiler（Babel 插件形式）的项目，短期没有任何变化。

如果你想提前观察 Rust 版的编译行为，可以关注 React 仓库的 compiler-crates 目录结构：

# 克隆 React 仓库并查看 Rust 编译器相关目录
git clone https://github.com/facebook/react.git
cd react
# Rust 编译器代码位于 compiler 相关子目录
find . -path "*/compiler*" -name "*.rs" | head -20

# 如果你想本地构建 Rust 版编译器（需要 Rust 工具链）
rustup install stable
cargo build --manifest-path compiler/rust/Cargo.toml

对编译速度的预期

基于 SWC 和 Turbopack 的经验，Rust 重写后编译速度提升通常在 5-20 倍区间（取决于项目规模和分析深度）。React Compiler 的分析比纯语法转译更重（需要跨组件追踪依赖关系），所以实际提升幅度需要等基准测试公布后确认。

风险与边界

WASM 集成问题。Rust 编译器要嵌入现有构建管线（Webpack/Vite），需要编译为 WASM 或通过 native plugin 桥接。WASM 模式的启动开销和内存模型与 native Rust 有差异，这可能成为集成瓶颈。
调试体验降级。TypeScript 版出错时你可以直接读源码、打断点。Rust 版出错时，构建管线里的错误信息会经过 WASM 边界，可读性和调试链路都会变差。
生态兼容性。现有 React Compiler 的 TypeScript API、插件接口、Babel 集成方式都需要在 Rust 侧重新实现等价层。过渡期可能出现两套 API 不完全对齐的情况。

下一步该关注什么

如果你是 React Compiler 的使用者或关注者，建议做这几件事：

不要立刻切换实现。等官方发布基准测试和稳定性报告。
在大型项目上测量当前 TypeScript 版的编译耗时。记录基线数据，等 Rust 版可测试时做对比——这是最有说服力的迁移依据。
关注 WASM 集成方案。Rust 编译器最终要跑在你的构建工具里，集成方式决定了你是否需要改构建配置。
审视自己团队的 AI 编码实践。这次 PR 证明"AI 主导 + 人类导航"在领域专家手中可以产出高质量代码，但它也同时证明——没有那个专家，这套模式跑不通。

React Compiler 的 Rust 重写，表面上是语言选择，底层是编译工具链的性能天花板正在被逐一打破。而开发方式上的实验，可能比语言本身更值得长期追踪。