2026年7月，React团队将React Compiler的Rust移植版本合并进了主仓库。这不是一次普通的性能优化。它意味着你过去在
babel-plugin-react-compiler里跑的那层自动memoization，正在从“Babel插件”变成“打包器原生能力”。更直接的数据是：作为Babel插件的直接替换，Rust版本大约快3倍；独立的转换逻辑在部分场景下最高可达10倍提升。而在Vercel的大规模Next.js应用v0上，当编译器不再作为Babel插件运行、而是直接集成进Turbopack后，编译速度提升了超过40%。
React Compiler没变。变的是它跑在哪一层。
一、先搞清楚：React Compiler到底在做什么
React Compiler的前身是React Forget。它的职责非常单一：自动为组件和Hooks添加缓存优化，让开发者不再需要手写useMemo和useCallback。
过去的运行方式是：它作为一个Babel插件存在。你的打包器——无论是Webpack、Vite还是Turbopack——在构建过程中调用Babel，Babel再加载React Compiler插件，插件分析你的组件代码，插入memoization逻辑。
这条链路能用，但它有一个结构性的成本：Babel本身是一个JavaScript写的编译器，而你的打包器每次构建都要承担Babel的解析和转换开销。
Rust移植要解决的，就是这条链路里的“中间人税”。
二、Rust版快在哪里：不是“翻译了一遍”，而是“换了一个位置”
Rust版React Compiler的提速来自两个层面。
第一层：语言层面的原生速度。 Rust编译成机器码直接运行，没有JavaScript解释器开销，也没有JIT预热。移植团队重写了内部实现，使用了arena分配和基于索引的数据结构，所有1,725个测试样例通过，中间状态与TypeScript版本几乎逐字节匹配。作为一个Babel插件的直接替换，Rust版本的运行速度大约快3倍，独立转换逻辑在部分场景下最高可达10倍提升。
第二层，也是更关键的一层：位置层面的“去中间人”。 当React Compiler还是一个Babel插件时，打包器每次构建都要先启动Babel，再让Babel加载插件。而Rust版本可以直接集成进打包器本身。Vercel工程师Andrew Imm指出，之前SWC插件路径受到WebAssembly冷启动的拖累；当编译器直接进入Turbopack的Rust管线后，这部分成本被消除了。
在v0上，编译速度提升超过40%。Next.js官方数据则显示，路由编译速度提升范围为20%到50%，实验性支持随Next.js 16.3推出。
3倍是“换语言”带来的。40%到50%是“换位置”带来的。 后者才是这次移植真正改变游戏规则的地方。
三、生态已经开始动：不只Turbopack，Vite和Rspack也在接
React Compiler的Rust化不是“一个打包器的内部优化”。它正在成为整个Rust工具链的共享基础设施。
Oxlint已经添加了react/react-compiler规则，早期采用者React Spectrum和Sanity报告了5到6倍的性能提升。
Rolldown（Vite 8的底层打包器）已经合并了暴露React Compiler选项的PR，Vite和Rolldown用户即将可以通过transform.reactCompiler选项启用。
SWC的PR已经合并并随Rust crate v68.1发布，暴露了jsc.transform.reactCompiler配置项。
Rspack 2.1通过升级SWC，让builtin:swc-loader支持Rust版React Compiler。
这意味着什么？ 以前React Compiler是“React生态里的一个Babel插件”。现在它是“Rust工具链里的一个原生能力”。你用的打包器是Turbopack、Vite、Rspack还是SWC，都能在不同层面接入同一个编译器内核，而不是各自维护一套JavaScript胶水。
四、但社区真正担心的不是速度
Rust移植的消息在Hacker News上引发了另一种讨论。一位读者欢迎向编译型语言迁移，但警告说：“偿还认知债务将会非常痛苦，无论最终哪个团队长期维护这套代码。”
另一位用户则把这件事和Bun的Zig到Rust迁移放在一起比较，提出了一个更根本的问题：“LLM构建出来的基础是否足够可靠，可以在其上继续构建和迭代？还是说，这会导致项目最终变得无法维护，因为没有人真正理解实现细节？”
还有一条评论值得所有“Rust化”项目警惕：“仅仅因为某些东西是用Rust编写的，并不意味着它就是优秀的Rust。” 模型可能会为了满足借用检查器而选择RefCell，把潜在问题推迟到运行时才暴露。
这些担忧不是反对Rust。它们指向的是一个真实的风险：当移植工作大量依赖LLM完成机械性转换，人类工程师主要负责架构设计和代码审查时，代码库的“可理解性”是否跟上了“可运行性” 。
对于React Compiler这种直接修改用户组件语义的编译器来说，“没人看得懂”不是一个学术问题。编译器的一个错误memoization，可能在生产环境表现为一个难以复现的UI bug。
五、这对前端开发者意味着什么？
1. 你的构建配置可能变简单，而不是变复杂
如果你已经在用Next.js 16.3，React Compiler的Rust版是实验性内置的，不需要额外安装Babel插件。如果你用Vite + Rolldown，它正在变成transform层面的一个选项，而不是一个需要单独配置的Babel链路。
编译器正在从“你配置的东西”变成“打包器自带的东西”。
2. “自动memoization”的收益，开始不再被Babel成本吃掉
React Compiler的承诺是“不用手写useMemo和useCallback”。但如果启用它意味着构建时间翻倍，很多团队会犹豫。Rust版把这个成本压到了足够低——3倍到10倍的插件提速，加上集成进Turbopack后的40%以上整体提升。
当memoization的“价格”下降时，更多团队会愿意打开这个开关。
3. Rust工具链的“共享内核”效应正在显现
React Compiler同时出现在Oxlint、Rolldown、SWC、Rspack里，不是巧合。Rust生态正在形成一套可复用的编译器组件，不同的工具通过Rust crate互相组合，而不是各自用JavaScript重写一遍逻辑。
这对开发者的直接影响是：你在一个工具里获得的行为，会更快地在另一个工具里出现。 工具链的碎片化正在被Rust的模块化抵消一部分。
4. 但“Rust化”不等于“无脑升级”
社区对认知债务和LLM生成代码可维护性的担忧是合理的。对于React Compiler这种改变代码语义的工具，建议的采用方式是：
- 先在非核心页面或新项目上启用，观察memoization行为是否符合预期
- 保留关闭编译器的回退路径
- 关注React团队对Rust移植版的长期维护承诺，而不只是短期速度数据
写在最后
2026年7月，React Compiler的Rust移植版本合并进React主仓库。
它作为Babel插件快3倍，独立转换逻辑最高快10倍，集成进Turbopack后带来40%以上的编译提速。Oxlint、Rolldown、SWC、Rspack都在接入同一个Rust内核。
React Compiler没有改变它要做的事。它改变的是自己所在的那一层。 从“Babel生态里的一个插件”，变成“Rust工具链里的一个原生能力”。
速度是明面上的收益。结构性的变化是：编译器正在离开插件层，进入打包器的核心管线。 而当一个能力从“可选插件”变成“内置原生”时，它被打开的概率，会远高于被配置的概率。
参考链接：
