125秒到10秒：TypeScript 7.0用Go重写编译器，前端圈等了14年

如果你在一个大型 TypeScript 项目里工作过，一定熟悉这个场景：你保存了一个文件，切到别的窗口，等着编辑器里的红色波浪线追上来。在大型 monorepo 里，CI 上的 tsc --noEmit 是所有人都学会了"别盯着看"的慢步骤。

2026 年 7 月 8 日，微软正式发布了 TypeScript 7.0。14 年来，TypeScript 编译器第一次不是用 TypeScript 写的了。 它被从头到尾移植到了 Go 语言。带来的效果是：编译速度平均提升 10 倍 。VS Code 约 230 万行代码的类型检查，从 125.7 秒降到了 10.6 秒 。打开一个包含错误的文件，定位第一个错误的时间从 17.5 秒缩短到了 1.3 秒。

一、从 125 秒到 10 秒：数字不会说谎

微软官方公布了一组基准测试数据：

项目	代码规模	TypeScript 6.0	TypeScript 7.0	提升
VS Code	~230万行	125.7秒	10.6秒	11.9倍
Sentry	~190万行	139.8秒	15.7秒	8.9倍
Bluesky	~62.8万行	24.3秒	2.8秒	8.7倍
Playwright	~52.8万行	12.8秒	1.47秒	8.7倍
tldraw	~34.5万行	11.2秒	1.46秒	7.7倍

在 VS Code 项目上，完整构建从将近两分钟 压缩到了十秒出头。在 Sentry 上，从 139.8 秒降到 15.7 秒。Slack 的 CI 类型检查从 7.5 分钟降到了 1.25 分钟。

内存占用也明显下降：VS Code 项目构建内存峰值从 5.2GB 降至 4.2GB（降幅 18%），Bluesky 从 1.8GB 降至 1.3GB（降幅 26%）。

这不只是数字。这是 14 年来第一次，TypeScript 的类型检查不再是 CI 上那个「你泡杯咖啡等它跑完」的环节。

二、为什么能快 10 倍？拆开看就明白了

过去 14 年，TypeScript 编译器一直采用**"自托管"方式**------用 TypeScript 本身写编译器，再编译成 JavaScript 跑在 Node.js 上。

这套方案有三个天花板：

单线程瓶颈：Node.js 的事件循环是单线程的，类型检查无法跨文件并行
JIT 预热：V8 的 JIT 编译器需要预热时间，而编译器构建通常在达到峰值性能之前就结束了
GC 不匹配：V8 的垃圾回收器并非为抽象语法树产生的长生命周期、循环数据结构而设计

Go 一次性移除了这三个天花板：

编译成原生机器码，没有 JIT 预热，没有 JavaScript 解释开销
goroutine 实现了跨 CPU 核心的真正共享内存并行
Go 的并发垃圾回收器不会长时间暂停执行

微软自己的拆解是：一半提速来自原生代码执行，另一半来自多线程并行处理。两者叠加，就是 10 倍。

三、一个绕不开的问题：为什么是 Go，不是 Rust？

这是 2025 年 3 月移植计划公布时，所有人都问的问题。为什么不是 Rust？为什么不用微软自家的 C#？

TypeScript 的设计笔记给出了一个务实的答案。

编译器做了大量的图遍历工作------在多态节点之间上下行走树结构。Go 让这件事做起来很顺手，给了开发者对内存布局和分配的控制权，同时不需要让每一行代码都去思考所有权问题。

还有一个朴素的原因：idiomatic Go 看起来很像现有的 TypeScript 代码库------函数和数据结构，而不是深层的对象继承层次。这种相似性让移植几十万行代码变得可行，而不是变成一场耗时数年的重写。

TypeScript 创始人 Anders Hejlsberg 形容 Go 是 "仍然提供原生代码、垃圾回收器和良好并发性的最低级别语言" ，而且不会与 TypeScript 的编码风格产生冲突。

Rust 并没有错。Rust 正在 JavaScript 工具链的其他领域大放异彩------从打包工具到 pnpm 的 Rust 重写。但在 TypeScript 编译器这个特定的场景下，Go 是更合适的选择。

四、升级前必须知道的三件事

1. 你的代码不用改

TypeScript 7.0 没有新的类型系统，没有新的语法 。微软团队的移植策略是逐函数移植，而不是重新设计。两个编译器在 20,000 个测试用例中，只有 74 个存在行为差异------都是边界情况。

同样的类型系统，同样的 tsconfig，同样的报错信息。你不需要改一行业务代码。

2. 但有些框架现在不能升

这是一个重要的例外。TypeScript 7.0 不包含程序化 API 。这意味着依赖编译器 API 的框架------Vue 的模板类型检查、Svelte 的类型服务、MDX、Astro、Angular 的模板类型检查------在 7.0 上会出问题。

微软预计 TypeScript 7.1 将自带一个新的 API，目标时间大约是 2026 年 10 月。在此之前，这些框架的完整编辑器支持需要等待。

如果你的项目用了 Vue/Svelte/Astro/Angular，现在不是升级的时候。

3. 可以并行跑两个版本

微软发布了兼容包 @typescript/typescript6，提供了名为 tsc6 的可执行文件。你可以在安装 TypeScript 7.0 的同时继续使用 TypeScript 6.0，两者不会冲突。

过渡期可以这样对比：

bash 复制代码

npm install -D typescript@latest
npm install -D @typescript/typescript6

npx tsc --noEmit      # TS 7
npx tsc6 --noEmit     # TS 6

五、生态现状：谁已经上车了，谁还在等

已经可以升级的：

纯 TypeScript/JavaScript 项目
Node.js 后端项目
不使用框架模板类型检查的 React 项目

建议等待 7.1 的：

Vue 3 项目（依赖 Volar 的模板类型检查）
Svelte 项目
Astro 项目
依赖 typescript-eslint 等需要编译器 API 的工具链

GitHub 上已经能看到一些项目开始迁移：CopilotKit 已将发布的包迁移到 TypeScript 7.0.2，tldraw 也在跟进。typescript-go 作为移植过程的暂存仓库，将在 2026 年 9 月永久归档------这也意味着移植工作已经彻底完成。

写在最后

2026 年 7 月 8 日，TypeScript 7.0 正式发布。14 年来，TypeScript 编译器第一次不是用 TypeScript 写的了。VS Code 的类型检查从两分钟压到了十秒。打开一个包含错误的文件，响应速度提升了 13 倍。

这是一次"引擎更换"，不是一次"功能更新" 。把一辆车的发动机从 1.6L 自然吸气换成 3.0T 涡轮增压------外观没变，操作方式没变，但踩下油门的瞬间，感觉完全不同。

对大多数开发者来说，除了性能提升，几乎感觉不到任何变化。但如果你在大型 TypeScript 项目里工作过，这个变化你一定能感觉到。类型检查不再是 CI 上那个"泡杯咖啡等它跑完"的环节了。

命令行升级：

bash 复制代码

npm install -D typescript@latest

升级还是不升？取决于你的项目。纯 TS/JS 项目可以上了，Vue/Svelte/Astro 项目等 7.1。Go 重写不是重新设计，同样的类型系统，同样的 tsconfig，同样的报错信息。你不需要改一行业务代码。

评论区聊聊：你升级 TypeScript 7.0 了吗？大型项目的编译时间缩短了多少？