2026年8月4日，oxc团队为Rust版React Compiler发布正式支持，包名叫oxc-transform-react。做网站建站工具的Outlyne团队把自己1,036个文件的React Router代码库切了过去，编译阶段耗时从14.3秒降到0.81秒，提速约17.6倍。这个数字很抓眼球，但它只回答了半个问题——真正值得关注的，是Rust版编译器同时把此前一批常见语法从“跳过编译”变成了“正常编译”，这比单纯的速度提升更影响实际使用体验。
Vite生态同步跟进。@vitejs/plugin-react 6.1.0版本加入了“实验性原生支持”，配置里传入{ compiler: true }就能切换。如果项目用的是React Router framework mode，用不了Vite官方React插件，可以改用第三方插件@acusti/vite-plugin-react-compiler。
编译提速17.6倍,但那只是构建的一部分
Outlyne实测：编译器单项从14.3秒压到0.81秒，单线程状态下提速17.6倍，比Babel版快出一个量级——oxc项目负责人Boshen在自己的博客里给出的基准测试也是“比Babel快10倍以上”。
但同一份代码库，整体构建时间只从22.1秒降到9.3秒，提速2.4倍。原因很直接：编译只是构建流程里的一环，打包、类型检查、资源处理这些环节该花多久还是花多久。
拿单个1,036文件项目跑出的17.6倍去套所有项目的整体构建速度，是这轮消息传播里最容易踩的坑。项目规模、组件复杂度、其他构建步骤占比都会让这个数字上下浮动，2.4倍才是更贴近“整体体验”的参照。
比速度更值钱的,是JS兼容性追上来了
作者更看重的其实不是速度，而是Rust版编译器已经修掉了Babel版1.0还留着的几个bailout（跳过编译）场景：try/catch里的条件逻辑、解构出来的prop重新赋值后被内层闭包使用、计算对象属性键（比如clsx里动态拼key）。这三类此前都会让组件直接跳过编译，Outlyne因此多编译出7个函数。
停在Babel版就等于停在一个不会再更新的分支上
这句话点出了关键对比：Babel版React Compiler已经进入维护状态，不再吃到新的兼容性修复；Rust版还在持续迭代，未来的修复会自动落到用它的项目上。
不过“修复了一批”不等于“修完了”。作者提到，try块里直接throw，以及??=、&&=、||=这几种逻辑赋值写法，目前依然会触发跳过编译。
- 风险.仍有语法会让编译跳过组件，代码库里这类写法越多，收益打的折扣越大
迁移前,这三条边界要看清
三件事值得团队自己核对一遍，而不是照抄17.6倍这个结论。
一是版本门槛。原生支持依赖Vite 8以上版本，@vitejs/plugin-react的原生编译选项目前还是“实验性”，不是默认稳定路径。
二是框架适配。走React Router framework mode的项目用不了Vite官方React插件的compiler: true，得换成社区维护的@acusti/vite-plugin-react-compiler，这条路径的成熟度和官方插件不是一回事。
三是版本对齐。作者提到自己曾经因为Oxlint用的oxc-transform-react是0.145.0、构建用的是0.144.0，两边版本没对齐，误以为遇到了lint和编译结果不一致的bug——真相只是旧版本还没支持某个模式。统一lint和构建的编译器版本，能减少这种“看不出漏编译”的覆盖缺口，但不代表生产环境从此不会漏编译，团队自己的CI里还是得把版本锁死、跑一遍全量检查。
对维护大型React、Vite代码库、盯着GitHub Actions账单的团队来说，值得做的不是立刻抄配置，而是先在自己的项目里跑一次真实的全流程构建对比——编译阶段的提速有多亮眼，整体构建的提速就有多现实。