React 团队在 GitHub 上公开了一个实验性 PR，尝试将 React Compiler 从 TypeScript 移植到 Rust。PR 作者 Joseph Savona 明确写到，这是 work-in-progress，尚未在 Meta 内部完成测试，也没有可直接下载使用的构建产物。
这件事不能解读成 React Compiler 已经正式迁移到 Rust，更不能理解为即将默认启用。它更像一次提前放出的工程路线信号：React Compiler 想摆脱只围绕 Babel 插件运转的局限，向更高性能、更容易嵌入现代前端工具链的方向移动。
Rust 版还在移植路上，但架构选择已经摊开
这次 PR 的范围相当清楚：Rust 版沿用 TypeScript 版 React Compiler 的核心架构。编译器会把 AST 转成自己的 HIR（High-level Intermediate Representation），内部使用控制流图 CFG 和 SSA，并按 pass 逐步移植原有算法。
作者给出的正确性锚点是，1725 个 fixtures 在对比临时 Rust 插件与主版本时通过，比较内容包括生成代码和错误；逐 pass 的中间表示也做了对比，除部分 ID 归一化外基本一致。
| 项目 | 当前状态 | 对开发者的含义 |
|---|---|---|
| 发布形态 | experimental、WIP | 不能按生产依赖接入 |
| 构建产物 | 尚未提供 | 想试用需要自行折腾源码 |
| 架构 | AST → HIR，CFG + SSA | 不是重写算法，而是迁移实现语言 |
| 测试 | 1725 fixtures 通过 | 有早期可信度，但还不是内部验证结论 |
一个容易被忽略的限制是，Rust 版目前还不自己做 scope analysis。它的公共 API 暂时是“Rust 版 Babel AST + scope info 输入，Rust Babel AST 输出”。Babel、OXC、SWC 等集成方需要把各自 AST 转成这个形态，还要提供 scope 信息。
性能数字有吸引力，但别当最终 benchmark
作者提到，早期数据看起来不错：作为 Babel 插件运行约快 3 倍，实际转换逻辑约快 10 倍。由于序列化成本不低，最终收益被抵消了一部分；如果未来走 OXC、SWC 这类原生集成，理论上还会更快。
但这组数字的含金量要打折看。作者自己也说，benchmark 设置还没有充分验证，早期性能判断部分来自 AI 辅助发现的优化机会。对工程团队来说，这不是采购级或迁移级指标，只能说明方向值得跟。
横向看，前端工具链过去几年已经多次验证 Rust 路线的吸引力。SWC、OXC、Rspack 都在用 Rust 换取构建速度和并行能力。React Compiler 如果长期停留在 Babel 插件形态，很难吃满这一波工具链更新的红利。Rust 移植的意义正在这里：它不是为了“Rust 更时髦”，而是为了进入新的编译器生态位。
受影响的不是普通 React 用户，而是工具链团队
短期内，普通 React 开发者几乎不会有体感。不会因为这个 PR，项目里的 React 编译突然变快，也不会多一个稳定配置项。
真正需要读这条消息的是两类人：一是维护构建链的前端基础设施团队，二是 OXC、SWC、Babel 插件生态的集成者。对他们来说，接下来要判断的不是“要不要马上切 Rust 版”，而是 React Compiler 的公共 API 会不会稳定，scope 信息由谁负责，最终输出是整棵 Program 替换，还是作者提到的 patch 形式。
PR 里已经给出三个集成方向：一个替代 Babel 插件，以及 react_compiler_oxc、react_compiler_swc 两个示例 crate。这里的关键词是“示例”，不是稳定支持。OXC 和 SWC 集成看起来能跑，但作者也承认，手工验证程度还不如 Babel 路线。
接下来最该观察三件事：Meta 内部测试是否通过；React Compiler 是否实现自己的 scope resolution；公共 API 是否从返回 Option<Program> 改成更适合集成方的 patch。只有这些变量落地，Rust 版 React Compiler 才可能从工程实验走向生态基础设施。