React Compiler 是一項旨在簡化開發者心智負擔的技術，其核心目標是實現自動化處理記憶化（Memoization）。在傳統的 React 開發中，為了避免不必要的重複渲染，工程師必須手動使用 useMemo 或 useCallback 來快取計算結果或函數。而 React Compiler（原名 React Forget）則透過編譯階段的分析，自動幫開發者完成這些優化，讓程式碼更簡潔且效能更穩定。
為了進一步提升建置速度並深化與現代前端工具鏈的整合，Meta 決定將 React Compiler 從原先的 TypeScript 重新用 Rust 語言實作。這次遷移不僅是語言的更換，更是為了解決 JavaScript 在處理大規模抽象語法樹（AST）時的效能瓶頸。
為什麼選擇 Rust 以及效能提升的關鍵
對於 Junior 工程師來說，可以將編譯器想像成一個巨大的資料處理工廠，它需要讀取數千行程式碼，將其解析成樹狀結構，進行複雜的邏輯分析，最後再輸出優化後的程式碼。TypeScript 雖然開發速度快，但在處理這種高強度計算時，受限於垃圾回收（GC）機制與執行效率，速度較慢。
Rust 則提供了記憶體安全且接近 C++ 的執行效能。在這次移植中，開發團隊採用了 Arena Allocation（區域分配）與基於索引的資料結構（Index-based data structures）。簡單來說，Arena Allocation 是將相關的記憶體一次性申請一大塊，而非零散地申請許多小塊，這能極大減少記憶體碎片並加速分配速度。
根據測試數據，Rust 版本作為 Babel 插件運行時，速度比 TypeScript 版本快約 3 倍；而在純粹的轉換邏輯處理上，部分情境甚至能達到 10 倍的效能提升。
從插件到原生整合的實務影響
過去 React Compiler 是作為 Babel 插件運行的，這意味著建置工具（Bundler）在每次編譯時都要承擔 Babel 的執行開銷。而將其用 Rust 實作後，它可以直接整合進像 Turbopack（Vercel 開發的 Rust 驅動建置工具）這類的原生工具中。
這種原生整合消除了中間層的轉換損耗。在 Vercel 的大規模 Next.js 應用測試中，路由編譯速度提升了 20% 到 50%。這對開發者而言，最直接的感受就是 HMR（熱模組替換）速度變快，從修改程式碼到瀏覽器看到結果的等待時間顯著縮短。
AI 輔助開發與維護的爭議
值得關注的是，這次大規模的語言移植大量使用了大型語言模型（LLM）來處理機械性的程式碼轉換，人類工程師則負責架構設計與最終審核。這在開發社群中引發了討論。
一方面，LLM 確實加速了遷移過程；但另一方面，許多資深工程師擔心這會造成認知債（Cognitive Debt）。如果程式碼是由 AI 生成而缺乏深層的人類理解，後續維護者可能會發現實作邏輯變得晦澀難懂。此外，Rust 的借用檢查器（Borrow Checker）非常嚴格，若 AI 為了快速通過編譯而濫用 RefCell（一種允許在不可變引用中修改資料的容器），可能會將編譯時期的錯誤推遲到執行時期，增加 Runtime Crash 的風險。
前端工具鏈的 Rust 化趨勢
React Compiler 的 Rust 化並非孤例，而是前端生態系的一個大趨勢。目前許多核心工具都在經歷同樣的轉型，例如 SWC（快速的 JS/TS 編譯器）、Oxc（高性能的 Linter 與解析器）以及 Rspack。
這種趨勢的核心邏輯在於：當前端專案規模越來越大，JavaScript 本身的效能已不足以支撐極速的開發體驗，因此將底層工具鏈移至系統級語言（如 Rust）已成為必然選擇。
對開發者的影響與建議
對於大多數 React 開發者來說，這次底層語言的更換是透明的。公開 API 依然保持與 Babel 兼容，因此升級過程應該是無感的。
如果你準備開始使用 React Compiler，建議參考官方的漸進式採納指南。由於編譯器會強制執行某些規則，你可以先將不符合規範的舊程式碼排除在編譯範圍之外，逐步優化，而非一次性重寫整個專案。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。