TypeScript 7.0：用 Go 重写编译器，10 倍提速的另一面

2026 年 7 月 8 日，微软把 TypeScript 推向了 7.0——这是自 2012 年语言诞生以来最底层的一次重构。整个编译器从 TypeScript/JavaScript 被逐行移植到了 Go，内部代号 Project Corsa。Anders Hejlsberg 在 2025 年 3 月立下的「10 倍提速」军令状，十六个月后兑现了。

这不是又一次「类型剥离器」。esbuild、swc、Biome 这些工具做的是把类型擦掉、转译、跳过检查；TypeScript 7 是完整的类型检查器、声明文件生成器，全都在原生速度下跑。它把过去五年 JS 工具链「绕开 tsc」的尴尬局面收了口：快的路径不检查类型，检查的路径慢到只能在 CI 里跑——Slack 这样的团队每次合并都要在 CI 上烧几分钟。

基准：125.7 秒变 10.6 秒

数字不是合成微基准，是微软拿自己最大的公开代码库喂给编译器的真实结果：

• VS Code（约 230 万行）：125.7 秒 → 10.6 秒，11.9 倍
• Sentry：139.8 秒 → 15.7 秒，8.9 倍
• Bluesky：24.3 秒 → 2.8 秒，8.7 倍
• Playwright：12.8 秒 → 1.47 秒，8.7 倍
• tldraw：11.2 秒 → 1.46 秒，7.7 倍

早期采用者的反馈相互印证。Slack 的 CI 类型检查从约 7.5 分钟降到 1.25 分钟；微软自家的 News Services 团队声称每月因此省下约 400 个工程师工时。提速大约一半来自原生代码、一半来自共享内存多线程——这也解释了为什么编辑器也变快了：在 VS Code 代码库上，打开一个带错误的文件从 17.5 秒降到 1.3 秒以内。内存占用下降约 18%，语言服务崩溃显著减少。

为什么是 Go 而不是 Rust？2025 年社区为此抱怨过一轮，但 Go 恰恰是十六个月能交付的原因。Hejlsberg 的团队没有重设计编译器，而是近乎逐函数地移植——Go 的垃圾回收器和结构风格让这种移植可行，Rust 重写则做不到。正因为是移植而非重写，7.0 检查器的行为和 6.0 完全一致：同样的类型推断、同样的报错、同样的输出。这个性质让 10 倍数字可信，而不是「换了新代码库」的注脚。

唯一的大坑：7.1 才有 API

TypeScript 7.0 没有随附稳定的编程接口（programmatic API）。这不是脚注级的细节。typescript-eslint 的类型感知规则、Vue 的 vue-tsc、以及 Svelte / Astro / MDX / Angular 模板的语言工具，全部通过编译器 API 驱动，而它们一个都跑不了 7.0。微软说新 API 会在 7.1 落地，之后大约每三到四个月一个版本。

后果很具体。typescript-eslint 已发布的 peer 范围只允许 TypeScript 低于 6.1.0，装 7.0 时 npm 直接抛 ERESOLVE。ts-morph 的失败模式最阴：它不产生报错，而是默默输出错误结果。微软为此发了兼容包：npm install -D typescript@npm:@typescript/typescript6 把旧编译器和它的 API 留在别名下，而 typescript 指向 7。能用，但你的 node_modules 里同时住着两个编译器，两个版本可能漂移。

各框架现状：React / Next.js 完全支持，随时可升。Vue、Svelte、Astro、MDX 基础类型检查能用，但编辑器模板类型检查得等 7.1。Angular 仍在评估。webpack loader 因为没有 API 面也要等 7.1。

迁移建议：6.0 做桥，7.1 补洞

迁移路径是刻意设计的：6.0 是桥接版本，旧选项在那时变成弃用警告，7.0 把它们变成硬错误。所以先升 6.x、清掉警告，再动 7.0。

配置层面的破坏大多是有益的。strict 和 module: esnext 成为默认值，彻底移除 target: es5、baseUrl、moduleResolution: node10、downlevelIteration，以及 AMD/UMD/SystemJS 模块格式。还在出 ES5 的，微软正式退出这块业务，下游用 Babel 或 swc 转。中等代码库预留一天，baseUrl 引用到处都是的预留更多。

上了 7 之后，CI 里的新并行旋钮才显价值：--checkers（默认 4）控制并发类型检查线程，--builders 并行化项目引用。在强力的 CI runner 上拉高 --checkers 是旧编译器永远给不了的白捡速度。

诚实的采用判断是：如果你的工具链是 tsc 加打包器，现在就升——先过 6.0，再直奔 7。如果你依赖类型感知 lint 或框架语言工具，用兼容别名让 7 跑构建、类型感知部分先留 6，等 7.1 把新 API 坐实再全切。无论如何，别再把「类型检查很慢」当成工作流的物理约束了——这个约束刚过期。