如果你在一个大型 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，两者不会冲突。
过渡期可以这样对比：
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 上那个“泡杯咖啡等它跑完”的环节了。
命令行升级：
npm install -D typescript@latest
升级还是不升？取决于你的项目。纯 TS/JS 项目可以上了，Vue/Svelte/Astro 项目等 7.1。Go 重写不是重新设计，同样的类型系统，同样的 tsconfig，同样的报错信息。你不需要改一行业务代码。
评论区聊聊：你升级 TypeScript 7.0 了吗？大型项目的编译时间缩短了多少？
