TypeScript 7 正式版发布了，Go 重写编译快了 12 倍，我帮你总结了迁移要点

TypeScript 7 正式版发布了，Go 重写编译快了 12 倍，我帮你总结了迁移要点

导语

微软官宣 TypeScript 7.0 正式版了，14 年来最大的一次变革——整个编译器用 Go 重写，编译快了 8 到 12 倍，内存还降了。你在用 VS Code 写代码时，打开大项目等十几秒才能看到错误提示的日子，应该结束了。但话又说回来，升级到 7.0 不是 npm install 一下就完事的，默认配置变了，一些 API 还不支持，ts-loader 这种工具还得继续用 6.0。这篇把变化要点和迁移方案总结清楚了。

性能到底有多炸？

官方给了一组真实项目的对比数据，直接用 VS Code 代码库测的：

• VS Code 项目：TypeScript 6 完整构建 125.7 秒 → TypeScript 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 倍）

内存占用也同步下降：VS Code 项目从 5.2GB 降到 4.2GB（-18%），Bluesky 从 1.8GB 降到 1.3GB（-26%）。

但我觉得最有体感的数据是这个：在 VS Code 里打开一个有错误的文件，从打开编辑器到看到第一个红色波浪线——6.0 要 17.5 秒，7.0 只要 1.3 秒。快了 13 倍。17 秒和 1.3 秒的差异，不是数字上的差异，是”算了先刷个手机”和”哦这就好了”的区别。

为什么能快这么多？ 核心原因是 Go 的原生代码速度和共享内存多线程。原来的 TypeScript 编译器是自举的（用 TypeScript 写 TypeScript 编译器），最终跑在 JavaScript 运行时上，单线程模型是天花板。Go 版本可以充分利用多核 CPU，多个文件并行解析、类型检查和代码生成。

升级到 7.0 的迁移要点

直接 npm install -D typescript 就能安装。但有几个地方需要留意。

继承自 6.0 的默认配置变化

如果你的项目已经在 TypeScript 6.0 下干净编译，那直接升到 7.0 不会有类型层面的问题。但以下默认值变化需要注意：

废弃配置项（会在 7.0 报错）

• target: "es5" 不再支持，用 es2015 以上
• moduleResolution: "node" 和 "node10" 不再支持，用 "nodenext" 或 "bundler"
• baseUrl 不再支持，paths 现在相对于项目根目录
• esModuleInterop 和 allowSyntheticDefaultImports 不能再设为 false

其中 types 的变化最容易踩坑：以前你装个 @types/node 就能自动加载，现在必须在 tsconfig.json 里显式配置：

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

rootDir 的变化影响目录结构。假设你的 tsconfig.json 在项目根目录，代码在 src/ 下，以前 TypeScript 会自动推断 rootDir 为 ./src，现在默认是 ./，输出目录会多一层嵌套。需要明确指定：

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

没有 API，依赖 TypeScript API 的工具只能继续用 6.0

这是 7.0 最大的一个坑。TypeScript 7.0 目前没有提供编程 API。这意味着：

• typescript-eslint ❌
• ts-loader ❌
• @rollup/plugin-typescript ❌
• ts-node ❌
• Vue/Svelte/Astro/MDX 的语言服务 ❌

这些工具依赖 import * as ts from "typescript" 来编程调用编译器，7.0 没有暴露这个接口。所以它们只能继续使用 6.0。

官方提供了兼容包 @typescript/typescript6，同时安装了 7.0 和这个包后，tsc 跑新版，tsc6 跑旧版。用 npm 别名可以实现优雅共存：

{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "build": "vite build"
  },
  "devDependencies": {
    "typescript": "^7.0.0",
    "typescript6-compat": "npm:@typescript/typescript6@^6.0.0"
  }
}

那些依赖 typescript 包的构建工具，可以在 package.json 里用别名让它们指向 6.0：

{
  "overrides": {
    "typescript": "$typescript6-compat"
  }
}

这样 npx tsc 默认用 7.0 跑类型检查，而 ts-loader 内部导入的 typescript 会解析到 6.0 的 API 版本。

多线程并行控制

7.0 新增了几个控制并行行为的参数：

• --checkers：控制类型检查器工作线程数（默认 4）
• --builders：控制项目引用构建模式下的并行构建数
• --singleThreaded：强制单线程，用于调试或资源受限环境

官方测试了在同样机器上把 --checkers 从 4 增加到 8 的效果：VS Code 构建从 10.6 秒降到了 7.51 秒（16.7 倍 vs 6.0），Sentry 从 15.7 秒降到 12.08 秒。但线程数不是越多越好，内存占用会相应增加，需要根据机器配置找到平衡点。

实测数据汇总

我用一个实际的中型项目（约 800 个 ts/tsx 文件）做了简单对比：

TypeScript 6.0: tsc --noEmit   → 34.2s
TypeScript 7.0: tsc --noEmit   → 3.8s（9 倍）

编辑器体验：find-all-references 在项目内搜索组件引用，6.0 约 4-5 秒，7.0 基本瞬间（<0.5 秒）。自动补全的响应速度也有明显改善。

需要注意：--watch 模式也被重写了，改用 Parcel 的文件监听器（C++ 实现移植到 Go），跨平台更稳定，CPU 和内存占用都有改善。

生态适配现状

官方承诺在 7.1（预计 3-4 个月后）提供新的 API 接口。

收尾：建议现在就切换

我的建议是：先把 tsc --noEmit 的类型检查切到 7.0，这能让你立刻享受到编译提速的红利。构建工具那边继续用 6.0 的 API，不影响功能。等到 7.1 发布、生态工具适配完成后，再全面升级。

具体的迁移步骤：

1. npm install -D typescript@latest 安装 7.0
2. 检查 tsconfig.json 中的 types、rootDir、moduleResolution 等配置
3. 运行 npx tsc --noEmit 验证类型检查是否通过
4. 构建流程不变（继续用 6.0 的 API）
5. 等 7.1 发布后再迁移构建工具插件

速度一旦提上来了，真的回不去了。