React Compiler 的 Rust 移植版合并了：编译期优化正在从前端生态里长出来

React Compiler 的 Rust 移植版本已经合并，Next.js（canary）、Oxlint 1.70、swc 和 Rolldown 等项目陆续跟上。这件事的意义不在某个具体特性，而在方向。

React Compiler 在做什么

它把原来要人手写的 useMemo、useCallback、memo 这些记忆化代码，交给编译器自动插入。原理是静态分析组件的依赖关系，判断哪些计算可以复用。

问题在于：这是编译期分析，跑的是 JavaScript 实现，在大项目上耗时会成为构建瓶颈。Rust 重写解决的正是这个。

为什么是 Rust

前端工具链这几年在集体搬迁：SWC 换掉 Babel，Rolldown 换掉 Rollup，Oxlint 换掉 ESLint 的一部分，Rspack 换掉 Webpack。共同原因是同一个——JS 实现的工具在大型项目上撞到了性能天花板。

这不是语言崇拜。构建工具的特点是极度重复的字符串与 AST 处理，这类负载用 Rust 写，性能差距是数量级的，而且并行化容易。

对普通开发者的实际影响

短期几乎无感：构建快一点、HMR 快一点。中期有一个变化值得注意：编译器介入越深，代码写法的一致性要求越高。React Compiler 依赖它能正确推断依赖关系，遇到动态改写、隐式副作用这类模式会直接放弃优化（或报错）。这意味着“能跑就行”的写法会越来越吃亏。

一个提醒

新工具链的迁移风险主要在边界：CommonJS 兼容、monorepo 里的源码链接、自定义 Babel 插件。这些不是原理问题，是工程细节，但恰恰是最耗时间的部分。上生产前拿最复杂的那个子项目做试点。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

编译器介入越深，代码写法的一致性要求越高，这条影响比构建快几秒大得多。React Compiler 依赖它能正确推断依赖关系，遇到动态改写和隐式副作用会直接放弃优化。迁移风险主要在边界：CommonJS兼容、monorepo里的源码链接、自定义Babel插件。上生产前拿最复杂的子项目做试点。

想问这个 Rust 版本对普通业务项目有什么实际影响？我项目是 Vite 搭的，构建三十秒左右，感觉不到瓶颈。是不是只有组件特别多的大仓库才值得关心，小项目暂时可以先放着。

Rust 版合并最大的价值是把编译耗时压下来，JS 实现在大项目上跑一遍要几分钟，这个成本在 CI 里很痛。但自动插入记忆化有副作用，依赖分析算错的 bug 特别难查，最好能按文件粒度关掉。