2026年8月4日 oxc 团队发布 Rust React Compiler 的官方支持后，我们将拥有1036个文件的 React Router 代码库 Outlyne（一个网站构建工具）切换至该编译器，构建的编译器部分速度提升了约17.6倍。v6.1.0版本的 @vitejs/plugin-react 带来了实验性原生 React Compiler 支持，可通过在 Vite 配置中向插件传入 { compiler: true } 启用。
正文
oxc 团队在 2026 年 8 月 4 日发布了 Rust 版 React Compiler 的官方支持（oxc-transform-react）。我们把包含 1,036 个文件的 React Router 代码库 Outlyne（一个网站构建器）切了过去，构建中的编译器部分大约提速 17.6 倍。@vitejs/plugin-react 的 v6.1.0 也带来了“实验性原生 React Compiler 支持”，在 Vite 配置里给插件传 { compiler: true } 就能开启。要是没法用 Vite 的 React 插件（比如像我们一样用 React Router 的 framework 模式），还可以用 @acusti/vite-plugin-react-compiler 这个极简 Vite 插件，它不管构建管线其余部分是什么，都能对代码库做 React 编译。
更快的构建 = 开发者更开心 + CI 更便宜
这次改动最显眼的是速度。oxc 项目负责人 Per Boshen 说：“初步基准测试中，它比 Babel 快 10 倍以上。”我们的实测超过 17 倍：1,036 个文件用 Babel 要 14.3 秒，原生单线程只要 0.81 秒。这对我们很重要，因为在 agent 辅助开发的快节奏下，CI 用量和 GitHub Actions 分钟数已经成了实打实的成本中心；等 CI 也很让人沮丧，还给本来就足够碎片化的任务管理大脑继续施压。需要说明，这些加速只作用于构建中的编译器环节；完整构建通常还有其他事情要做，整体速度不会那么可观。我们这边完整构建从 22.1 秒降到 9.3 秒，约快 2.4 倍。
React Compiler 的限制呢？
速度虽然是头条，我更兴奋的是能用上最新版 React Compiler，它已经修掉了 Babel 版 v1.0 里仍存在的不少实质限制。比如 try/catch 块中的任意条件逻辑，这在最初 1.0 稳定版上挡了很多人的路。另一个上周刚落地的修复是：解构出来的组件 prop 被重新赋值后又放进嵌套闭包使用，比如先给 prop 一个默认值、再在 onClick 里读取；以前编译器会跳过这种组件，现在支持了。还有第三种过去会让 Babel 编译器放弃优化的常见模式也支持了：计算对象属性键，例如根据 itemCount 动态生成 items-${itemCount} 这样的键。这些修复让新版编译器在我们的应用里多覆盖 7 个函数：5 个来自 try/catch 改进，2 个来自计算键。限制也依然存在。我现在实际遇到过、仍会让编译器跳过组件或 hook 的写法有两种：从 try 块中抛出 throw，以及逻辑赋值运算符（??=、&&=、||=）。留在 Rust 编译器这边，以后这些修复会陆续到来；困在已经没有后续的 Babel 编译器上，就别指望了。
工具链一致，覆盖不留盲区
我乐意切换构建的最后一个原因，是整个工具链现在使用同一个 React Compiler 版本，功能支持完全等价。早前我的构建还用着较旧的 React Compiler，同时开始用 Oxlint 的 React Compiler 支持，于是基于上面说的“解构 prop 被跳过”问题，我给 oxc 报了一个其实不成立的 issue：组件在构建时没被优化，lint 也没报错，让我以为 lint 和编译结果脱节。真正原因是 Oxlint 用的是 oxc-transform-react v0.145.0，那个模式已经支持；而我测试用的是同一个包的 v0.144.0。现在 lint 和构建跑同一个 React Compiler，改进和限制完全一致，不用担心未编译组件漏进生产构建。
用法
使用 @vitejs/plugin-react
如果你已经在 Vite v8+ 上，把现有 React Vite 构建迁到原生 React Compiler 基本等于做减法。Babel 路线目前的安装说明是装 @rolldown/plugin-babel，并在 Vite 配置里同时启用 react() 插件和带 reactCompilerPreset() 预设的 Babel 插件。原生路线只需安装 oxc-transform-react，再把配置简化成给 react() 传 { compiler: true }，同时还能从 devDependencies 里删掉 @rolldown/plugin-babel。
不使用 @vitejs/plugin-react（例如 React Router 的 framework 模式）
对使用 React Router framework 模式的代码库，迁移稍有不同：React Router 自带 Vite 插件，用来取代 Vite 的 React 插件。以前需要安装 vite-plugin-babel、babel-plugin-react-compiler 和 @babel/preset-typescript，并在 Vite 配置里让 reactRouter() 与一个配好 TypeScript preset 和 React Compiler 插件的 Babel 插件协同工作。现在可以彻底丢掉这三个依赖，只安装 @acusti/vite-plugin-react-compiler，配置简化成 plugins: [reactRouter(), reactCompiler()]；如果还要传自定义的 compiler 配置，reactCompiler({ compiler: { ... } }) 也可以。
评论
社区整体对移除 Babel 普遍持欢迎态度，同时也有不少开发者对 Next.js 仍需要 Babel 插件、与 React 新编译器的兼容性等问题提出疑问。
认为可以彻底移除 Babel，编译流程更简洁
- 开发者对编译管线中不再需要 Babel 感到非常开心，认为这能简化构建配置（较高兴度） > 我的编译管线里终于不用再放 Babel 了，太好了（@adzm）
质疑 Next.js 集成的 React 编译器为何仍需 Babel 插件
- 不少人注意到 Vite 版本已无需 Babel，但 Next.js 基于 SWC 却还要额外加 Babel 插件，对此感到困惑，认为不符合技术选型逻辑（较多人） > 既然 Next.js 用的是 SWC，为什么它的 React 编译器版本还需要 Babel 插件，而 Vite 版本却不需要？（@Onavo）
关心新编译器与 React 新特性的兼容性
- 有人提出疑问，想知道这套方案能否配合 React 新推出的、用于优化各类 Hooks 的编译器正常工作（少数人） > 这个方案能和 React 那套用来优化各种 Hooks 的新编译器一起用吗？（@syspec）
有价值的补充
- OXC 的转译速度远快于 Babel，已有开发者基于 OXC 和 Vite 构建跨 Web、iOS、Android 的框架，用 OXC 替代 StyleX 的 Babel 样式转换，用 Vite 替代依赖 Babel 的 Metro 打包器，早期体验下速度提升非常明显（@vmsp）