TypeScript 7.0 新特性

TypeScript 7.0 不是一次常规的版本迭代。它是微软对 TypeScript 编译器的一次”换心手术”——把整个编译器和语言服务从 TypeScript/JavaScript 移植到了 Go 语言。代号 Project Corsa。

2026 年 7 月 8 日，7.0 正式发布（7.0.2 是当前最新稳定版）。本章基于官方公告和公开资料，把这次大版本的变化讲透。

Corsa 的由来：为什么用 Go 重写

从 2025 年 3 月说起。微软 TypeScript 首席架构师 Anders Hejlsberg 在一个公开视频中宣布：TypeScript 团队正在做一个 Go 语言的原生移植。这就是 Project Corsa。

在那之前，TypeScript 编译器的运行路径是这样的：

TypeScript 源码（.ts）
  → 编译成 JavaScript
    → 运行在 Node.js / V8 引擎上
      → 处理你的 TypeScript 代码

相当于用 TypeScript 写的编译器编译你的 TypeScript 代码。这套”自举”架构在 2012 年到 2025 年之间撑了 13 年，但随着项目规模膨胀，性能瓶颈越来越明显。

切换到 Go 的核心理由就一个：原生性能。Go 编译成机器码直接运行，没有 JavaScript 引擎的 JIT 预热、没有 V8 的 GC 暂停、没有单线程事件循环的限制。而且 Go 原生支持多线程和共享内存，并行处理是天生的。

经过约 15 个月的公开开发——2025 年 3 月宣布、2026 年 4 月 Beta、6 月 RC、7 月 GA——TypeScript 7.0 如期发布。

性能飞跃：官方数据和你能感受到的

官方在 VS Code 仓库上做的全量构建测试，数字很有说服力：

指标	6.x（JS）	7.0（Go）	提升
完整构建	125.7 秒	10.6 秒	11.9×
编辑器打开含错文件延迟	~17.5 秒	<1.3 秒	~13×
增量构建（热重载）	~4.3 秒	~0.48 秒	~9×

来源：官方博客 Announcing TypeScript 7.0，VS Code 仓库（约 170 万行 TypeScript 代码）。

这些数字在你自己项目上的表现取决于项目规模。一个小项目（几十个文件）可能感觉不出差别——1 秒变 0.1 秒，肉眼看不出来。但如果你是几十万行代码的 monorepo 维护者，这 10 倍提升就是饭碗级体验改善。

编辑器体验的改善更直观。以前在 VS Code 里打开一个含错文件，类型检查延迟可能让你先看到红色波浪线闪现再消失——因为类型检查是异步的。7.0 把这个延迟砍到秒级以内，编辑器响应几乎实时。

新默认值：更严格的 tsconfig

7.0 改了几个编译选项的默认值。这些变更不是”改个数字”那么简单——它们直接影响旧项目能否不经修改就直接升级。

strict: true（原为 false）

这是影响面最大的变更。以前你需要手动写 "strict": true，现在不写就默认开启。

如果你的旧项目从来没开过 strict，用 7.0 编译大概率会爆出一堆类型错误。这其实是好事——严格模式帮你发现潜在的运行时 bug。但修复工作量取决于代码量，需要提前评估。

module: “esnext”（原为 “commonjs”）

7.0 默认产出 ESM 格式的模块代码。这对前端项目（Vite/Webpack）和现代 Node.js 项目都是正确的选择。但如果你还在用老的 CommonJS 工具链（比如 ts-node 的旧版本），记得显式写 "module": "commonjs"。

target 下限 ES2015（移除了 es3/es5）

target 不再接受 es3 和 es5。最低只能设 ES2015。这个变化对绝大多数项目没影响——2026 年还在用 es5 target 的项目几乎不存在了。但如果你维护的是一个需要兼容 IE11 的老项目，需要注意这一点。

types: []（原默认加载所有 @types/*）

TypeScript 以前会自动扫描 node_modules/@types/ 下所有包的类型声明并加载。这在大型 monorepo 里会导致类型冲突和编译变慢。

7.0 改成默认空数组 []，只加载你显式引入的类型声明。如果你发现升级后某些 @types/xxx 包的类型找不到了，手动加到 types 字段就行：

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

并行检查器：—checkers 和 —builders

Go 原生多线程让 TypeScript 终于可以并行做类型检查了。7.0 引入了三个命令行参数：

—checkers N

控制类型检查 worker 的数量。默认 4 个。

npx tsc --checkers 8   # 用 8 个 worker 做类型检查

每个 worker 有自己独立的”世界视图”——它完整加载项目，独立检查分配给它的文件。检查结果汇总后由主进程编排输出。

官方标注这个功能是实验性的，但默认已经开启了 4 个 worker。如果你遇到奇怪的并行相关 bug（概率很低），可以用 --singleThreaded 暂时退回到单线程模式。

—builders N

控制 --build 模式下并行构建项目引用的 worker 数：

npx tsc --build --builders 6

这个参数也是实验性的，默认关闭。对于有多个子项目的 monorepo，它能大幅减少总构建时间。

stableTypeOrdering

这不是命令行参数，而是一个编译器内部策略——默认开启、不可关闭。它保证并行类型检查的输出顺序在不同机器、不同运行时都一致，让 CI 构建结果可复现。

—singleThreaded

开发调试时用的开关。关闭所有并行，让编译过程变成单线程顺序执行，方便排查问题：

npx tsc --singleThreaded

移除项清单：这些真的没了

7.0 移除了几个历史选项。不是弃用（deprecated），是直接移除（removed）——用了就报编译错误。

移除的 target 值

• "es3" ~ "ES3"
• "es5" ~ "ES5"

如果旧配置里写了这两个值，改为 "ES2015" 或更高。

移除的 module 值

• "amd"
• "umd"
• "system" / "systemjs"

这三个模块格式在 2013 年前后流行过，但早已不是主流。AMD（RequireJS）、UMD（万能模块）、SystemJS 在现代前端工程中几乎没有新项目在用。迁移方案：

• AMD → esnext（用打包工具处理模块）
• UMD → 打包工具会自己生成 UMD 包，不需要 tsc 参与
• SystemJS → esnext

移除的 moduleResolution 值

• "node10"（旧名 "node"）

改为 "bundler"（前端项目）或 "node16"（Node.js 项目）。

这些移除项在 TypeScript 6.0 时已经被标记为弃用（deprecated）。如果你在 6.0 期间已经做了迁移，7.0 不会给你额外痛苦。如果你直接从 5.x 跳 7.0，这些移除项需要一次性清理。

框架兼容性：谁现在能升级、谁该等等

这是 7.0 最容易被忽略但最重要的一点。TypeScript 7.0 不提供公开的编译器 API。

为什么这很重要？因为 Vue（Volar）、Svelte、Astro、Angular 等框架在背后用到了 TypeScript 的编译器 API 来做模板类型检查。TS 7.0 的 Go 编译器目前还没暴露这些 API。

官方在公告中明确建议：

来源：Announcing TypeScript 7.0

如果你只是纯 .ts / .tsx 项目（不依赖框架特定的模板类型检查），现在就能升级到 7.0。编译更快、默认更严格，收益立竿见影。

简单判断清单：

项目类型	能否升级 7.0	说明
纯 TypeScript 应用（Node.js CLI、后端服务）	✅ 可以	无框架依赖，直接升级
React + .tsx	✅ 可以	React 的 TS 类型检查不依赖编译器 API
Vue 3	⚠️ 暂缓	钉在 6.0，等 7.1
Svelte / SvelteKit	⚠️ 暂缓	钉在 6.0，等 7.1
Astro	⚠️ 暂缓	钉在 6.0，等 7.1
Angular	⚠️ 暂缓	钉在 6.0，等 7.1
Next.js / Nuxt	取决于底层	纯 .ts/.tsx 页面可以，但框架底层可能需要 6.0

7.1 路线图：什么时候能全面升级

根据官方公告，TypeScript 7.1 预计在 2026 年 10 月 左右发布。7.1 的核心目标是：

• 提供稳定的编译器 API——这是框架生态能迁移到 7.x 的前提
• 在此基础上，Vue/Volar、Svelte、Astro、Angular 等框架可以适配 Go 编译器

在那之前，纯 TypeScript 项目享受 10 倍性能，框架项目继续用 6.0。两边不冲突。

升级检查清单

如果你的项目打算从 6.x 升级到 7.0，按这个清单逐项检查：

1. 确认项目类型：纯 .ts/.tsx 项目？可以升。Vue/Svelte/Astro/Angular？暂缓。
2. 检查 target：旧配置里写了 "es5"？改成 "ES2015" 或更高。
3. 检查 module：旧配置里写了 "amd" / "umd" / "system"？改成 "esnext" 或 "commonjs"。
4. 检查 moduleResolution：旧配置里写了 "node" 或 "node10"？改成 "bundler" 或 "node16"。
5. 评估 strict 影响：之前没开 strict？先在你的 6.x 环境里打开试一遍，修完类型错误再切 7.0。
6. 处理 types 字段：如果依赖某些 @types/xxx 包的类型全局可用，手动加到 "types": ["node", "jest"]。
7. 更新 CI 脚本：7.0 的 tsc 更快，可以把 --checkers 加到构建命令里试试。
8. 跑一遍完整构建：npx tsc --noEmit 确认没有新错误。

小结

TypeScript 7.0 的核心变化就一条：编译器从 JavaScript 变成了 Go。这带来了：

• ~10 倍性能提升：构建从分钟级降到秒级，编辑器反馈几乎实时
• 更严格的默认配置：strict: true、module: esnext、target >= ES2015、types: []
• 真正的并行检查：--checkers 和 --builders 利用 Go 多线程
• 移除历史包袱：es3/es5、AMD/UMD/SystemJS、node10 正式退出舞台
• 框架生态暂缓：Vue/Svelte/Astro/Angular 等 7.1 再升，纯 TS 项目现在就能收益

这次版本升级对 TypeScript 生态的影响远大于 3.0→4.0→5.0→6.0 的任何一次迭代。好消息是，团队刻意保证了语义兼容——只要你处理好配置变更，升级后代码行为完全不变，只是快了很多。