TypeScript 7.0 上手：编译器用 Go 重写后，我的 CI 快了 10 倍

2026 年 7 月 8 日，TypeScript 团队发布了 7.0。这不是一次普通的版本升级——他们把整个编译器用 Go 重写了一遍。

我花了一个周末把两个项目迁了上去。这篇文章聊一下实际体验：到底快了多少、迁移踩了什么坑、以及哪些项目现在还不适合升级。

为什么是 Go？

TypeScript 编译器之前是用 TypeScript 写的，跑在 Node.js 上。这个架构有一个先天问题：JIT 预热、单线程瓶颈、内存占用高。大型项目的类型检查动辄几分钟，编辑器里打开一个文件要等十几秒才能看到错误提示。

团队选择 Go 的原因很务实：

• 编译为机器码，没有 JIT 预热，启动即全速
• goroutine 天然适合并行化编译任务，多核利用率高
• 跨平台分发只需一个二进制文件，不需要 Node.js 运行时

重写策略也很克制：尽可能忠实地移植原有逻辑，保持类型检查的语义一致性，在此基础上利用 Go 的并发模型做并行化。

实际快了多少？

官方公布了一组公开 benchmark，我用自己项目的实测数据也基本吻合：

项目	TS 6 编译时间	TS 7 编译时间	加速比
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

如果机器核数够多，把 --checkers 调到 8，vscode 能跑到 16.7 倍。

我的项目（大概 300 多个文件，中等规模）tsc --noEmit 从 23 秒降到了 2.4 秒。不是什么巨型 monorepo，但这个差距已经足够改变工作习惯了——以前跑一次类型检查我会切出去干点别的，现在敲完命令结果就出来了。

内存也降了。vscode 的编译峰值从 5.2GB 降到 4.2GB，减少了 18%。这对 CI 环境和 16GB 内存的笔记本都是好事。

编辑器体验：终于不用等了

比构建速度更让我惊喜的是编辑器体验。以前在 VS Code 里打开一个大型 TypeScript 文件，从打开到看到红色波浪线大概要 10-15 秒——你打开文件，然后等。现在这个时间缩短到了 1-2 秒，基本可以做到"打开即见"。

根据团队公布的数据，VS Code 自身的编辑器首次错误提示从 17.5 秒降到了 1.3 秒以下。Canva 的数据是从 58 秒降到 4.8 秒。Slack 团队说他们的大型代码库之前在编辑器里"基本不可用"，开发者只能靠 CI 做完整类型检查，现在几秒就能加载，本地类型检查变得切实可行。

语言服务器也完全重写了，基于 LSP 协议的多线程架构。根据遥测数据，新版减少了超过 80% 的命令失败率和 60% 的服务器崩溃率。

迁移踩坑实录

官方建议先升级到 TS 6，再从 6 迁到 7。如果你的项目在 TS 6 下能干净编译，迁到 7 基本不会有意外。但如果你的项目还在 TS 5 甚至更早，建议分两步走。

我迁移时遇到的实际问题：

1. rootDir 默认值变了

TS 7 默认 rootDir 是 ./（项目根），不再是自动推断。如果你的源码在 src/ 目录下，不加这行就会报错：

{
  "compilerOptions": {
    "rootDir": "./src"
  }
}

2. types 不再自动加载

以前 @types/node、@types/jest 这些包会自动加载。TS 7 默认 types: []，需要手动声明：

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

3. 废弃选项变成硬错误

这几个我项目中用到的配置直接报错了：

• target: "es5" —— ES5 编译目标正式退役。如果你的项目还需要支持 IE 或老版本浏览器，得先解决这个问题。
• moduleResolution: "node" —— 必须改成 "bundler" 或 "nodenext"。
• esModuleInterop: false —— 不能再关，始终为 true。

路径别名的写法也变了。baseUrl 彻底移除，paths 改用相对项目根的写法。

4. JSDoc 类型注解需要调整

如果你的项目重度使用 JSDoc 做类型注解（比如不用 .ts 只写 .js 的项目），有几个变化要注意：

• @enum 不再识别，改用 @typedef
• Closure 风格的 function(string): void 语法不支持了，改成 (s: string) => void
• 后缀 ! 不再支持类型断言

哪些项目暂时不能升级

这是目前最大的限制：Vue、Svelte、Astro、MDX 的项目暂时不能用 TS 7。

原因很简单——这些框架把 TypeScript 嵌入到了自己的编译器和语言服务中，需要调用 TypeScript 的 API。而 TS 7.0 还没有暴露稳定的程序化 API。团队承诺在 7.1（预计 2026 年 10 月）中解决这个问题。

Angular 项目可以部分使用：命令行用 TS 7 跑 tsc 获得快速的全项目错误检测，编辑器里继续用 TS 6 获得模板内的类型支持。

如果你用的是 React / Next.js / Node.js 纯后端项目，基本可以放心升级。

兼容方案：同时装两个版本

过渡期可以同时装 TS 6 和 TS 7，通过 npm 别名：

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

这样 npx tsc 用的是 TS 7 编译，而 typescript-eslint 等依赖 API 的工具继续用 TS 6。团队还发布了 @typescript/typescript6 兼容包，提供 tsc6 命令和完整的 TS 6 API。

值不值得升？

值得，但有条件。

如果你的项目是纯 TypeScript（React / Node / Next.js 等），不依赖 Vue/Svelte 等嵌入式框架，而且已经在 TS 6 上跑得比较干净——强烈建议升级。构建时间从分钟级降到秒级，编辑器响应从"等一会儿"变成"瞬间"，这种体验提升是实打实的。

如果你的项目还在 TS 5 甚至更早，建议先迁到 TS 6，消化掉默认值变更和废弃警告，再上 7。

如果你的项目是 Vue/Svelte/Astro——等 7.1 吧。现在升了编辑器里没有类型提示，得不偿失。

TypeScript 7.0 不是终点。7.1 会补齐 API 缺口，之后团队会回归新功能开发。编译器重写这场硬仗打完了，接下来才是好玩的部分。