一個 1,036 個檔案的 React Router 網站建置器，將 React Compiler 從 Babel 路徑切換至 Oxc 的 Rust 實作後，編譯器階段由 14.3 秒降至 0.81 秒，約快 17.6 倍；完整建置則由 22.1 秒縮至 9.3 秒，約快 2.4 倍。這組數字出自 Outlyne 團隊的實際遷移紀錄，而非跨專案標準化評測：https://blog.master.dev/react-now-rusted-all-the-way-out/。
事件背景：React 最後一段 Babel 路徑正在被取代
React Compiler 是建置時最佳化工具，會分析元件與 Hook，自動加入相當於 memoization 的最佳化，降低開發者手動使用 useMemo、useCallback 與 React.memo 的需要。這是 React 官方對其功能的定義：https://react.dev/learn/react-compiler。
過去 Vite 即使已把一般 JSX、TypeScript 與 React Fast Refresh 轉換交給 Oxc，啟用 React Compiler 時仍需透過 Babel 外掛。2026 年 8 月釋出的 @vitejs/plugin-react 6.1.0 加入「實驗性原生 React Compiler」支援；在 Vite 8 安裝 oxc-transform-react，並設定 react({ compiler: true }) 即可啟用。Vite 外掛的正式變更紀錄可交叉確認版本、設定方式及「experimental」標示：https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/CHANGELOG.md。
速度從哪裡來：少一次 AST 翻譯，少一套執行環境
來源事實：Oxc 說明，早期整合必須先把 Oxc 的抽象語法樹轉成 Babel 形狀，執行編譯器後再轉回來。如今 Oxc 將 Rust 版 React Compiler 納入自身程式碼，直接在 Oxc AST 上運作，移除中介 AST 與 JSON 往返，也降低記憶體配置。其初步測試顯示速度超過 Babel 版十倍，並以超過 100 個大型熱門儲存庫、逾 10 萬個原始碼檔案比對輸出一致性：https://oxc.rs/blog/2026-08-18-react-compiler-support。
合理推論：17.6 倍並非單靠「Rust 比 JavaScript 快」即可解釋，更重要的是資料不必跨越兩套 AST 表示與外掛邊界。這代表工具鏈整合程度可能比程式語言標籤更能決定建置效能。
作者觀點：真正重要的不是單項 benchmark 奪冠，而是 React 專案中原本殘留的 Babel 專用階段開始可以移除。當解析、React Compiler、JSX 轉換與 lint 共用較一致的底層能力，設定與版本錯位也可能隨之減少。
為何現在值得注意
原案例不只得到速度提升，也發現 Rust 路徑支援了部分舊版 Babel 編譯器會放棄最佳化的程式模式，包括特定 try/catch 條件邏輯、計算式物件鍵，以及重新指定解構 prop 後在巢狀 closure 使用。對該專案而言，因此多了七個函式可被編譯。
更具長期價值的是一致性。案例曾因 Oxlint 與建置端使用不同版本的 oxc-transform-react，出現 lint 沒警告、正式建置卻未最佳化的落差。讓檢查與轉換使用相同編譯器版本，可降低這類「工具各自正確、整體結果卻不一致」的盲點。對快速增加程式碼的團隊，這往往比單次省下幾秒更有治理價值。
17.6 倍不能直接套用到你的專案
這份案例沒有交代處理器、記憶體、作業系統、重複次數、離群值、冷熱快取與完整量測腳本；唯一明確條件是 Rust 測試為單執行緒。因此它足以證明「這個專案確實大幅改善」，卻不足以推導所有千檔 React 專案都會得到相同比例。
數字本身也揭示阿姆達爾定律式的上限：編譯器快 17.6 倍，整體建置只快 2.4 倍，因為依賴解析、打包、CSS、資產處理、型別檢查及 I/O 不會同步消失。若 React Compiler 原本只占少量時間，遷移效益自然有限；CI 費用是否下降，也應以完整工作流程時間衡量，而不是只看 transform microbenchmark。
此外，Oxc 官方文件仍把功能標為實驗性，提醒選項與行為可能變動。編譯器必須在其他 JSX 改寫之前讀到原始碼；Emotion 的部分 Babel 轉換或其他會先改寫 JSX 的外掛可能衝突。違反 React Rules 的程式碼，以及依賴可觀察式 mutation 的模式，也可能被跳過而非最佳化：https://oxc.rs/docs/guide/usage/transformer/react-compiler.html。
對台灣前端團隊的實際意義
若團隊已有 Vite 8、@vitejs/plugin-react 6.1 以上與 React Compiler，這次遷移的表面成本不高：加入選用依賴、開啟 compiler 選項，並移除只為 React Compiler 存在的 Babel 路徑。但「設定只有一行」不等於可以直接全面上線。較穩健的作法是先在同一台 CI runner 比較完整建置時間、產物與測試結果，再逐步擴大。
React Router framework mode 等不能直接使用 Vite React 外掛的架構，原作者另提供第三方最小化外掛；它不等同 Vite 官方整合，團隊仍須個別檢查維護者、版本鎖定、source map 與發布風險。React 17、18 專案也要確認 compiler target 與額外 runtime，而不能照抄 React 19 的預設。
後續觀察指標
- 完整 CI 的中位數與高百分位時間，而非只看 React Compiler 階段。
- 被編譯、被跳過與產生診斷的元件數量，版本升級後是否出現覆蓋率變化。
oxc-transform-react、Oxlint 與 Vite 外掛是否鎖在相容版本，source map 與錯誤位置是否可靠。- 官方何時移除「實驗性」標示，以及仍未完成的語法路徑與診斷是否持續收斂。
這次變化不是 Babel 生態立刻退場，而是前端工具鏈的分工邊界再往原生整合移動一步。17.6 倍是吸睛案例；更值得追蹤的，則是速度、相容性與診斷能否在真實專案中同時成立。