配了三年 React，每次改完代码等编译等得想开掉下一个 useMemo——今天这件事被 Rust 版 React Compiler 从根上翻了

每次改完代码等编译，等得想开掉下一个 useMemo——今天这件事被 Rust 版 React Compiler 从根上翻了。

Meta 在 2026 年 6 月把 React Compiler 重写成了 Rust，合并进了 React 主仓库（PR #36173）。这不是修修补补，是把整个编译器从 TypeScript 倒腾成了 Rust，架构一模一样，但跑起来完全是两个速度。

先说数字。作为 Babel 插件直接替换，Rust 版本比 TypeScript 原版快约 3 倍；单独跑转换逻辑，最高跑到 10 倍。当然序列化有开销，把真实收益拉低了一些，但 Vercel 工程师在 Next.js 大型应用 v0 上实测，编译速度提升超过 40%；Next.js 官方账号给出的范围是 20-50% 路由编译加速，实验性支持已进入 Next.js 16.3（turbopackRustReactCompiler 标志位）。

为什么这么快？核心不是 Rust 比 TypeScript 快，是它终于不用再走 Babel 那层 transform 了。以前 React Compiler 作为 Babel 插件跑，每次构建都要经过 JS 执行环境，有 WebAssembly 冷启动的额外开销。现在直接链接进 Turbopack，二进制级集成，零桥接开销。

有人会说：12.3 万行代码是 LLM 写的，靠谱吗？确实，这个移植大量靠大语言模型做机械性翻译，人类工程师负责架构设计和代码审查。Hacker News 上有人担心「认知债务」——代码能跑、测试全过、输出逐字节一致，但长期维护怎么办？这个问题目前没有答案，Rolldown 维护者 Boshen 甚至暂时撤回了集成，先做了一轮「去除垃圾化」。但有一点是确定的：1725 个测试样例全部通过，架构层面的正确性有保证。

对前端团队来说，这意味着什么？如果你的项目用 Next.js + Turbopack，升级到 16.3 并打开实验性标志位就能用，不用改一行配置。生产构建收益取决于编译器在总构建时间里的占比——340 路由、1200 组件的 Next.js 应用，冷构建从 4 分 52 秒降到 3 分 8 秒（-36%），编译器阶段本身提速 73%，内存占用还降了 37%，CI 上的偶发 OOM 也顺带修了。小应用收益会小一些，Webpack 用户几乎感受不到。

下一步：先在 staging 环境实测一下你的端到端构建时间，不要轻信头条数字。每个项目的编译器占比不同，收益也不同。如果你在 Next.js 16.3+，加个 --turbopack-rust-react-compiler 标志位量一下就知道了。