你以为 React Compiler 只能跑 Babel？今天 Rust 把这件事从根上翻了

如果你知道React Compiler但以为它只能跑Babel，今天这个认知被Rust彻底翻了。

Oxc团队2026年8月发布了React Compiler的Rust实现——oxc-transform-react，接入Vite生态只需一行配置。Oxlint现在内置22条React Compiler规则，oxc-transform-react编译速度比Babel快10倍以上。实测：Outlyne团队把1036个文件的React Router代码库迁移过去，编译阶段从14.3秒压到0.81秒，提速17.6倍。

这个数字抓眼球，但它只回答了半个问题。真正值得关注的，是Rust版同时把此前一批常见JS写法从”跳过编译”变成了”正常编译”——这比单纯的速度提升更影响实际使用体验。

三行配置切过去

需要在Vite 8项目里：

npm install -D @vitejs/plugin-react@^6.1.0 oxc-transform-react

然后在vite.config.js里加一行：

import react from "@vitejs/plugin-react";
export default defineConfig({
  plugins: [react({ compiler: true })],
});

就完了。Oxc团队把包发布在 @vitejs/plugin-react 里，不污染Vite或Rolldown本身，核心工具链保持厂商中立。

Vite团队把这次集成标记为”实验性”，官方文档明确写着”生产使用前请审查生成的输出”。保守选型可以继续走Babel路径：@rolldown/plugin-babel + babel-plugin-react-compiler，但如果你愿意接受实验标签，就是上面三行的事。

编译快了17.6倍，然后呢？

Outlyne实测数据很清晰：

编译单项提速17.6倍，但整体构建只快2.4倍。原因很直接：编译只是构建流程里的一环，打包、类型检查、资源处理这些环节该花多久还是花多久。如果你的项目瓶颈在别处，感知不会那么明显。

但编译速度本身的价值不是线性收益。编译越快，HMR反馈越快，开发体验越接近”改完就看到”。对于大型monorepo，这个差异是切实可感知的。

比速度更值钱的，是JS兼容性追上来了

React Compiler需要识别特定代码模式才能安全地注入memoization。Babel版有个老问题：遇到拿不准的语法会直接跳过，跳过就不优化，等于白跑。

Rust版的兼容性更紧。Outlyne在迁移报告里列了一批”从跳过变成正常编译”的代码模式——具体是什么模式官方没有全量披露，但这个迁移本身说明了一个信号：之前不敢上React Compiler的项目，现在可以试试了。

当然还有边界：逻辑赋值（logical assignment）等特定写法仍可能跳过编译。这和Babel版的历史遗留问题有关，不是Rust版引入的，但用户需要知道。

三个坑

版本对齐是隐形的门槛。@vitejs/plugin-react 6.1.0声明的optional peer是oxc-transform-react@^0.145.0，但npm install会拉到0.147.0——Oxc官方明确说这是预期的，不是装错了。装完建议跑一下版本验证，确保实际加载的是匹配版本。

必须是Vite 8。@vitejs/plugin-react 6.x全系列只支持Vite 8，用Vite 6或7的同学只能走回Babel路。

实验性标签不是谦虚。生成代码里确实包含import { c as _c } from "react/compiler-runtime"和$[n]缓存槽位——功能是正常的，但建议在测试环境充分验证输出再上生产。

三步下一步

1. 跑一下基准：在现有项目里time npm run build，记录整体时间，然后切换过去再跑一遍——只比编译数字没意义，要看整体构建。
2. 检查eslint-plugin-react-hooks配置：如果你的项目配了严格的hook规则，React Compiler会自动处理memo优化，手动规则可能会冲突，先把现有配置注释掉测一下。
3. 看输出：加{ compiler: true }后，用npx vite build --mode development跑一下，审查dist里的代码是否有异常。

结论

React Compiler的Rust版不是对Babel版的简单替换。它解决了两件事：Babel版因为兼容性保守而跳过的代码现在能编译了，工具链版本终于在lint和build之间对齐了。速度是顺带的收益，真正的价值是覆盖度。

对Vite 8项目来说，三行配置的成本已经足够低。如果你的团队在用React Compiler或者想用但被Babel性能劝退过，现在的时间点值得再试一次。