等了一年多，TypeScript 的 Go 版終於真的來了。我看到正式版消息時確實有點興奮，畢竟誰不想讓 editor 少轉幾秒；但興奮完馬上想到 Vue、eslint、MDX 和那些靠 compiler API 吃飯的工具。重寫 compiler 很帥，等整個生態追上它，恐怕才是比較麻煩的下半場。
2025 年公布的原生編譯器計畫，在 TypeScript 7 變成正式版本。最容易誤會的地方是：TypeScript 這門語言沒有改成 Go，改用 Go 的是我們平常執行的編譯器和編輯器工具。
這次改寫主要是為了大型專案的處理速度。一般開發者不需要理解 Go 的細節，只要知道 tsc、型別檢查和編輯器提示背後換了新的實作。
不過重寫過的工具不可能保證每個舊設定都原封不動。升級前可以先查看官方相容性說明、更新相關 plugin，並留意專案使用的特殊 compiler option。對普通專案來說，重點是更快的工具，而不是一批全新的 TypeScript 語法。
語言相容，比跑分快更重要
大家看到原生重寫，第一個想到的通常是速度；但 TypeScript 每天被數百萬個專案使用，真正困難的是讓同一段程式得到相同型別結果。若新 compiler 快很多，卻到處多報或漏報錯誤，升級成本反而更高。
因此一般開發者可以先關注三件事：既有 tsconfig 是否支援、編輯器 extension 是否切到新語言服務，以及常用 build tool 是否已整合。等這些周邊跟上，再享受原生工具帶來的改善就好，不需要為了第一時間升級而冒險。
這也讓 2025 年的移植公告和 2026 年正式版形成一組文章：前一篇談為什麼重寫，這一篇談重寫完成後使用者會遇到什麼。引用速度數據時標明是官方資料，把重點放在升級和相容性，內容就已經足夠完整。
我的升級順序會從 editor 開始試，但不會先改全公司的預設。找一個大型 workspace 比較開啟、跳轉定義、重新命名和錯誤更新，再把 CLI 放到 CI 平行跑。兩套 compiler 結果不同時先留下案例，不要急著用 skipLibCheck 把差異蓋掉。
原生工具若成功，最大的改變可能不是大家突然寫出更複雜的型別，而是少一點等待後，工程師更願意保持 typecheck 常開。工具速度最後影響的是工作習慣，這比單次 build 快幾秒更有意思。