TypeScript 7.0：用 Go 重写的十倍速编译器，到底快在哪

2026 年 7 月 8 日，TypeScript 团队（Daniel Rosenwasser 署名）正式发布 TypeScript 7.0——一个用 Go 语言从头原生重写的 TypeScript 编译器。官方给出的主线数字是”全量构建普遍 8–12 倍提速”。这不是又一个 minor 版本：从 JavaScript 自举到 Go 原生，是近年编译器领域规模最大的一次移植。本文回到官方公告，把它的实测数据、并行机制和必须注意的迁移代价拆清楚。

一、背景：为什么要重写

TypeScript 过去十年靠”给 JavaScript 加上类型检查”支撑起了整个前端工业界，但随着仓库长大，编译器本身成了瓶颈——大仓库里打开一个文件、等第一个红波浪线出来可能要十几秒。微软的解法不是在旧 JS 代码上继续打补丁，而是用 Go 重写整个编译器，目标是吃满现代多核硬件：原生代码速度、共享内存多线程，以及一批新优化。

值得强调的是它的移植策略：官方称是”尽可能忠实（faithfully）“地翻译——写新代码的同时保持原代码库的结构与逻辑，目的是让两代编译器行为一致、结果可复现。这也是为什么它敢在 1.0 版本就喊”生产可用”。

二、关键数据：快多少、省多少内存

官方在五个知名开源仓库上跑了 TS6 与 TS7 的全量构建（默认 --checkers 4），数据如下：

内存占用反而更低（聚合整个构建周期）：

编辑器体感提升更夸张：在 VS Code 代码库里打开一个含错误的文件，从”打开编辑器到看到第一个错误”从约 17.5 秒降到 1.3 秒以内（13 倍以上）。团队侧的佐证包括：Slack 称 CI 类型检查从约 7.5 分钟降到 1.25 分钟、合并队列时间减少 40%；Canva 看到首个错误的时间从约 58 秒降到 4.8 秒；微软新闻服务团队称每月省下 400 小时 CI 等待。官方还称新语言服务器让失败的语言服务器命令减少 80% 以上、崩溃减少 60% 以上。

三、技术机制：多线程并行与可调节

TS 7 把解析、类型检查、产物发射（emit）都并行化。解析和 emit 基本可跨文件独立完成，扩展性好；但类型检查不行——文件之间依赖同一批类型信息和全局作用域，而且类型检查对信息顺序敏感。

它的解法是：创建固定数量的类型检查 worker，每个 worker 有自己的”世界视图”，可能重复一些公共计算，但给定相同输入文件，划分方式永远一致、结果永远一致，从而避免不确定性。默认 4 个 type-checker worker，可用新 flag --checkers 调节；还有 --builders 调节项目引用构建、--singleThreaded 彻底关掉并行（调试或资源受限环境用）。

官方实测把 --checkers 提到 8，同一台机器上 VS Code 构建从 10.6s 进一步降到 7.51s（16.7x）、Sentry 12.08s、tldraw 1.06s——但代价是更多内存。官方明确提醒：在核少、内存小的 CI runner 上，反而要把 checkers 调低。这不是”无脑更快”，而是一个需要按机器调参的旋钮。

--watch 模式则完全重写，底层基于 Parcel 的 @parcel/watcher（从 C++ 移植到 Go，只留少量 assembly shim，避免引入 C++ 工具链），跨平台文件监听更稳、更省资源。

四、迁移代价：这是最容易被忽略的一节

1. 7.0 不带公开 API。 官方原话：TypeScript 7.0 does not ship with an API，预计 7.1 才会带一个”不同的新 API”。在此之前，仍需编程式访问编译器的工具（最典型是 typescript-eslint）无法直接切过来。微软因此发布了兼容包 @typescript/typescript6（提供 tsc6 可执行文件并重新导出 TS6 API），配合 npm alias 让 tsc 走 7.0、而 ESLint 等工具仍依赖 6.0。

2. 默认配置变了一批。 7.0 采用 6.0 的新默认：strict 默认 true、module 默认 esnext、target 默认紧邻 esnext 的稳定版本、types 默认 []、rootDir 默认 ./。其中 rootDir 和 types 被官方自己点名为最”反直觉”的两个——tsconfig 不在 src 旁的项目要手动加 rootDir，依赖全局声明的要显式列出 types: ["node","jest"]。

3. 一批废弃项变成硬错误。 target: es5、moduleResolution: node10、baseUrl、module: amd/umd/systemjs/none 等不再支持；esModuleInterop:false、alwaysStrict:false 也不能再设。从旧项目升级不是改个版本号那么简单。

4. 一个微妙的破坏性变化：模板字面量类型现在按 Unicode 码点切分，不再按 UTF-16 码元——以前把 emoji 切成两个孤立代理对的行为被修正。对那些刻意模拟 UTF-16 行为的类型级字符串工具（如某些 string Length 库）是 breaking change。

五、评测口径与适用判断

• 上述提速表是微软在自家硬件上、默认 checkers=4 测得的；--checkers 8 的数字是同机补充实验，不同项目、不同 CPU/内存组合结果会漂移，官方也明说”results will differ across projects and underlying machines”。
• “8–12x” 是全量构建区间，编辑器首错误、CI 类型检查属于不同场景，体感提升可能更大或更小，别把 11.9x 当成你项目的保证值。

适合现在就上：monorepo、大仓库、CI 排队时间长的团队；主要用 tsc / 编辑器 LSP、不深度依赖编译器编程 API 的项目。

先观望：Vue（Volar）、Svelte（svelte-check）等嵌入式语言工作流依赖旧的 TS 语言服务 API，官方建议等 API 稳定；重度依赖 typescript-eslint 自定义规则、或被上面那批 breaking 默认项卡住的老项目，建议先升到 6.0 适配 deprecations，再上 7.0。

六、它意味着什么

TypeScript 7.0 的意义远超”编译器变快”：它证明了一个被千万项目依赖了十年、逻辑极度复杂的编译器，可以用”忠实逐行翻译”的方式整体移植到系统语言，同时把行为差异控制在可测试范围内。对大仓库而言，17.5 秒→1.3 秒的首错误时间，直接决定了”本地类型检查到底可不可用”——这是开发反馈闭环的质变。但它不是无痛升级：没有公开 API、一堆默认项反转、嵌入式框架工具链要等，意味着框架生态的整体迁移会比单个 CLI 命令慢半拍。普通业务项目可以尝鲜，框架维护者请再等等。

参考来源

• Microsoft DevBlogs：Announcing TypeScript 7.0
• Koala 项目库条目：TypeScript 7.0