React Compiler 迁移 Rust 后更快了，但开发者担心“没人看得懂代码”

React 是 Meta 开源的用户界面构建库，目前已将 React Compiler 的 Rust 移植版本合并到主代码仓库中。这一举措旨在提升构建速度，并加强与更广泛的基于 Rust 的 JavaScript 工具链之间的集成。React Compiler 过去被称为 React Forget，它会自动为组件和 Hooks 添加缓存优化，因此开发者不再需要手动调用 useMemo 和 useCallback。此次 Pull Request 将该编译器从 TypeScript 重写为 Rust，团队在 PR 中将其描述为“一个实验性的、正在开发中的移植版本”。性能是此次改动最受关注的数据。作为一个可直接替换的 Babel 插件，Rust 版本的运行速度大约比原 TypeScript 版本快 3 倍，而独立的转换逻辑在部分情况下最高可达到 10 倍提升，不过序列化开销会拉低实际使用中的收益。根据 Rust Bytes Newsletter 的介绍，所有 1,725 个测试样例均通过，中间状态与 TypeScript 版本几乎逐字节匹配。这一成果通过使用 arena 分配以及基于索引的数据结构重建内部实现而达成。最明显的收益出现在编译器不再作为插件运行之后。由于此前 React Compiler 是通过 Babel 转换运行的，打包工具每次构建都会承担这部分开销；而将 Rust 版本直接集成到 Vercel 的 Rust 打包器 Turbopack 中，则可以消除这一成本。Vercel 工程师 Andrew Imm 表示，在使用公司自研的大规模 Next.js 应用 v0 进行测试时，这一改动带来了超过 40% 的编译速度提升。他指出，之前的 SWC 插件路径受到了较长的 WebAssembly 冷启动影响。Next.js 官方账号则表示，在其测试应用中，路由编译速度提升范围为 20% 到 50%，实验性支持将在 Next.js 16.3 中推出。此次移植大量依赖大语言模型完成机械性工作，人类工程师则主要负责架构设计和代码审查，这也成为外界讨论的焦点。在 Hacker News 上，一位读者欢迎向编译型语言迁移，但警告称：“偿还认知债务将会非常痛苦，无论最终哪个团队长期维护这套代码。”另一位用户则将这一做法与类似的 Bun 项目进行了比较，同时也质疑了在此类项目中使用 LLM 的长期影响：继 Bun 之后，这是又一个通过大量使用 LLM 进行移植的高关注度项目。非常好奇这些重写最终会如何发展。LLM 构建出来的基础是否足够可靠，可以在其上继续构建和迭代？还是说，这会导致项目最终变得无法维护，因为没有人真正理解实现细节？同一讨论中的另一位用户提醒说：“仅仅因为某些东西是用 Rust 编写的，并不意味着它就是优秀的 Rust。”因为模型可能会为了满足借用检查器的要求而选择使用 RefCell，并将潜在问题推迟到运行时才暴露。现有用户基本不会受到此次变化的影响。公开 API 仍保持类似 Babel 的形式，因此升级目标是直接替换，保持现有配置不变：对于刚开始使用该编译器的团队，可以参考 React 的介绍文档和渐进式采用指南，其中说明了如何排除不符合要求的代码，因此整个代码库无需一次性完成修改。这次重写也符合 Rust 在前端工具领域持续扩张的趋势。SWC 已迁移到官方 Rust 编译器，Oxc 将其作为可发布的 crate 引入，而 Rspack 2.1 则提供了原生支持。不过，并非所有集成都顺利完成；Rolldown 维护者 Boshen 表示，团队已经撤回了其在 Rolldown 和 Vite 中的 Rust React Compiler 集成，以便先进行“去除垃圾化（de-slopify）”处理，尽管早期结果显示性能最高提升可达 2 倍。该 Rust 移植版本位于 React monorepo 中，可以通过 React Compiler 工作组持续跟踪其进展。原文连接：https://www.infoq.com/news/2026/07/meta-react-compiler-rust/