TypeScript 7.0 正式發布：編譯器換成 Go，開發實測快 10 倍

VS Code 自己的程式碼庫，150 萬行 TypeScript，過去用 tsc 做一次完整型別檢查要 77.8 秒。現在，7.5 秒，快了 10.4 倍。

這不是行銷簡報上的估計值，是微軟拿自己維護的最大專案跑出來的實測數字。而且這次加速的來源也不是調校演算法或加點快取——微軟做了一件 TypeScript 十幾年來沒做過的事：把底層編譯器從 TypeScript/JavaScript 整個換成 Go 重寫。

TypeScript 7.0 已經正式發布，這是它第一個底層編譯器不是自己寫自己的穩定版。十幾年來第一次，TypeScript 不自己寫自己了。

為什麼要放棄「自己寫自己」

TypeScript 從一開始的定位就是「JavaScript 的 typed superset」，連編譯器本身都刻意用 TypeScript 寫，一方面驗證語言自己夠不夠強，一方面也算是某種招牌——連自己的核心工具都信得過自己設計的語言。這個做法撐了十二年。

問題出在規模。當一個專案大到幾十萬、上百萬行，型別檢查要對整棵語法樹反覆遍歷、比對，JavaScript 引擎（V8）的執行速度和單執行緒的限制就變成天花板，怎麼調都調不動。TypeScript 團隊自己講得很直接：他們一度也想過用 AI 直接把整個編譯器從 TypeScript 翻譯成 Go，結果不理想——這件事我們在《TypeScript 的創造者談 AI：無聊的事丟給它，有趣的留給你》寫過細節，簡單說就是：翻譯 50 萬行程式碼，AI 偶爾會幻覺出誤差，逐行檢查比自己重寫還累，最後團隊選擇手工、逐步、可驗證地把邏輯移植過去，而不是丟給 AI 一次性翻譯。

最後拿到的加速數字，官方拆成兩塊解釋：一半來自原生程式碼本身比 JavaScript/V8 執行快，另一半來自 Go 可以用共享記憶體做真正的多執行緒平行運算——這件事 JavaScript 引擎在架構上做不到，就算你把邏輯寫得再精簡也繞不過去。

具體數字：不只 VS Code 快，幾個主流專案都快

VS Code 從 77.8 秒降到 7.5 秒；Sentry 從 133 秒降到 16 秒；TypeORM 從 17.5 秒降到 1.3 秒；Playwright 從 11.1 秒降到 1.1 秒——規模越大的專案，加速幅度越明顯，因為平行化的效益會隨著檔案數量疊加。

編輯器體驗的數字也不含糊：VS Code 專案在 language service 裡的載入時間，從 9.6 秒降到 1.2 秒，快了 8 倍，記憶體用量大約砍半。這代表你打開一個大專案等自動完成、等紅色底線出現的那段空白時間，明顯縮短。

「移植」跟「重寫」差在哪，這決定你要不要馬上升級

這裡有個容易被忽略但很關鍵的字眼：官方一直強調這是「port」（移植），不是「rewrite」（重寫邏輯）。

差別在哪？重寫代表團隊重新設計了一套型別檢查的邏輯，行為可能跟舊版有落差。移植代表刻意盡量照抄原本 TypeScript/JavaScript 版本的架構跟判斷邏輯，逐行轉譯成 Go，目標是讓兩個編譯器對同一份程式碼給出一模一樣的型別檢查結果。

這個決定不是保守，是刻意的風險控管——型別檢查器裡藏著大量「沒寫在文件裡，但實際行為就是這樣」的邊界情況，重新設計等於要重新踩過一次所有的坑。移植的代價是工程上更累，換來的是你的專案升級時，型別檢查語意基本不變，出錯機率低很多。

也因為這樣，npm install -D typescript 現在裝到的就是 Go 版編譯器，tsc 這個指令名稱沒變，用法也沒變。過渡期用的 tsgo 執行檔和 @typescript/native-preview 套件名稱，之後只會留在每晚建置的 nightly 版本裡。

什麼情況要先觀望：Compiler API 還沒到

TypeScript 7.0 唯一明確劃了線的地方，是程式化 API（Compiler API）——也就是 typescript-eslint、ts-morph、自訂 transformer，以及 Vue（Volar）、Svelte、Astro、Angular 模板型別檢查器這些直接呼叫編譯器內部介面的工具，目前都還吃不到新版。官方把穩定 API 排進了 7.1，預計會在幾個月後（大約 2026 年 10 月前後）落地。

換句話說：如果你只是每天跑 tsc 編譯、做 CI 型別檢查，或是純 React / Next.js / Node 專案，現在升級沒有阻礙，CI 時間立刻有感。如果你的專案框架依賴上述那些工具鏈，編輯器裡的型別提示、模板診斷可能會直接失效，得先按兵不動，或是裝一個相容包同時保留舊版 API 給那些工具用。

型別系統在 AI 大量參與寫程式碼的現在只會越來越重要，不是越來越沒必要——這個角度我們在《AI Coding 時代的工程師工具鏈》也談過：AI 生成的程式碼你看不到它怎麼想，型別系統是少數能把「這段程式碼有沒有照預期跑」釘死的東西。TypeScript 生態圈一大堆工具，包括像用 TypeScript 直接打 MCP 的 MCPorter這類 CLI 專案，都直接綁在編譯器的行為語意上——這正是為什麼「語意要完全一致」這件事，對整個生態圈的影響比表面數字更大。

開發變快，不是網站變快——這件事一定要說清楚

這次的加速，全部發生在你寫程式碼的過程：編輯器啟動、自動完成反應速度、紅色底線出現的快慢、CI 裡的型別檢查和 build 時間。跟你部署上線後、使用者實際打開網站或 App 的執行效能沒有關係。

這是個容易被誤會的地方——很多人看到「快 10 倍」直覺聯想成「網站變快了」，但編譯器只負責把你寫的 TypeScript 轉成 JavaScript、順便幫你抓型別錯誤，轉換完之後跑在瀏覽器或 Node.js 裡的，還是原本那份 JavaScript，執行效能取決於你的程式邏輯，不是編譯器換了什麼語言寫。

真正有感的人，是每天在等 CI 跑完型別檢查的團隊，或是打開一個大型 monorepo，等自動完成等到分心去看手機的開發者。

對開發者實際的意思

編譯器變快之後，卡住你的瓶頸可能不再是軟體這一層。如果你的機器本來就是舊款筆電、風扇狂轉、開一個大專案就頓，編譯器再快也補不了硬體的差距；如果你的桌面本來就亂糟糟，鍵盤打字體驗差、螢幕角度不對、線材纏成一團，這些跟「等待時間變短」是兩件不同的事，值得一起檢視。開發環境的順手程度，直接影響你願不願意每天多開幾次專案——像蝦皮開發者桌面四件套編輯選物這類機械鍵盤、USB-C Hub、螢幕掛燈、站立書架的組合，是不少人整理開發桌面時的起點，3,000 元以內就能補齊基本盤。

利益揭露：本文部分連結為聯盟連結，點擊購買我會獲得回饋，不影響你的購買價格。

常見問題

TypeScript 7.0 現在能升級嗎？

如果你的專案只是純 TypeScript/JavaScript，跑 CLI 編譯或 CI 型別檢查，現在就能升級，跑 npm install -D typescript 裝到的就是 Go 版編譯器。但如果專案依賴 Vue、Svelte、Astro、Angular 的模板型別檢查，或是 typescript-eslint、ts-morph 這類吃 Compiler API 的工具，要等 TypeScript 7.1（預計 2026 年 10 月前後）才有穩定的程式化 API。

TypeScript 7.0 會改變我寫的程式碼語法嗎？

基本不會。官方講得很清楚，這是「port」不是「rewrite」——刻意照抄原本 TypeScript/JavaScript 版本的型別檢查邏輯轉譯成 Go，目的就是讓兩個編譯器的檢查結果盡量一致，你的程式碼不用因為換了編譯器實作語言而跟著改。

編譯器變快，是我的網站跑起來也變快嗎？

不是。這次加速全部發生在開發階段——編輯器啟動、自動完成、型別檢查、build——不影響你部署後網站或 App 的執行效能。使用者體驗跟這次升級沒有直接關係，變快的是你自己寫程式的過程。

為什麼微軟選 Go，不選當紅的 Rust？

TypeScript 團隊表示 Go 的結構跟現有編譯器架構更接近，垃圾回收機制也讓大量存在的循環資料結構不用重新設計；Rust 的所有權模型會逼團隊大幅改寫核心邏輯，等於半個重寫，風險反而更高。

十二年前，TypeScript 的整個賣點是「我們只是想把 JavaScript 壞掉的地方修好」。十二年後，它自己的編譯器承認了一件事：有些效能問題，靠同一層語言修不好，得換一層語言寫才是對的答案。如果你的 CI 每天都在為型別檢查排隊，現在裝一次新版 typescript，這個決定值不值得，你自己跑一次就知道。