TypeScript 7 原生编译器：一次编译速度的量级提升，与必须处理的迁移清单

TypeScript 7 是这门语言十年来最大的一次底层变更：编译器从 JavaScript 实现换成了 Go 实现的原生二进制。带来的直接结果是类型检查与编译速度的量级提升，以及大型单体仓库终于能吃到的”秒级全量检查”。

但版本号跳跃也意味着迁移成本。本文讲清 TS 7 到底改了什么、哪些写法会被挡住、以及一份可照抄的渐进迁移清单。

一、版本坐标

截至 2026 年 9 月，typescript 的 npm dist-tags 大致是这样的状态：latest 为 7.0.2，rc 通道为 7.0.1-rc，next 通道指向 7.1.0-dev，而 beta 通道上还留着 6.0.0-beta。版本号可以在 npm 上的 typescript 包页面随时核对。

这里有个容易混淆的点需要讲明白：6.x 和 7.x 不是简单的先后关系，而是”两条线”。6.x 延续原有的 JavaScript 编译器实现，主要承担兼容与过渡职责；7.x 则是全新的原生实现，是未来的主线。选错分支会在升级时白跑一趟。

二、TS 7 到底换了什么

一句话：编译器本体被重写了，语言本身基本没变。

TypeScript 团队长期面临的一个结构性问题是，用 JavaScript 写的编译器在超大仓库上做全量检查时，单线程性能和内存占用都到了瓶颈。项目越大，tsc --noEmit 越慢，IDE 里的类型提示就越迟钝。原生实现的目标就是把这层天花板掀掉。

对使用者的意义很直接：同样的代码，检查更快、内存更省、编辑器响应更跟手。对于几万文件的 Monorepo，全量检查从”分钟级”压到”秒级”是常见的数量级变化。CI 里跑类型检查的时间成本下降，也会连带影响流水线的排队与并发策略。

三、语言层面：哪些写法要改

原生实现为了换取性能，收紧了一批历史上”能过但语义模糊”的写法。迁移时最先卡住项目的通常是下面几类。

1. 依赖未声明类型的隐式行为

老编译器在某些场景下会”宽容地放过”类型信息缺失的情况，比如从无类型的 .js 文件里推导出的 any 再参与运算。原生实现倾向于更早、更严格地报错。这类问题的修法很朴素——把隐式 any 显式化：

// 迁移前：handler 的入参被推导为 any，静默通过
import { handler } from './legacy-helper.js'
handler(event)

// 迁移后：显式标注，把不确定性摆到台面上
import { handler } from './legacy-helper.js'
handler(event as unknown as AppEvent)

2. 装饰器与实验性选项

如果你的项目重度使用装饰器（尤其是 Angular、NestJS 这类框架），需要重点回归测试。装饰器的元数据发射与求值顺序是原生实现中最容易与旧行为产生差异的地方。建议在迁移分支上先跑一遍完整的框架构建与运行时冒烟，而不是只看 tsc 是否报错。

3. 自定义 transformer 与编译器 API

这是最硬的一块。直接依赖 typescript 内部 API 的工具链（老版本的代码生成插件、自定义 transformer）在原生实现下大概率失效，因为内部数据结构不再是同一套 JavaScript 对象树。

排查顺序建议：

• 先检查 tsconfig.json 里有没有配置 plugins；
• 再检查构建工具链里是否有依赖 ts.createProgram、ts.transform 之类 API 的脚本；
• 对无法替换的插件，考虑把对应能力前移到构建阶段（比如用 Babel/SWC 插件或独立的代码生成脚本），让类型检查只做类型检查。

四、迁移清单：四步走

不要一次性切主分支。推荐按下面的顺序推进，每一步都能独立回退。

第 1 步：先把类型错误清零

在旧版本上把 strict 下的类型错误全部修完，并让 CI 强制拦截。带着一堆既有错误去迁新版，会分不清哪些是新版引入的。

# 先在当前版本上确认基线
npx tsc --noEmit

第 2 步：用独立分支并行跑

在 CI 里新增一个”实验性”任务，用 TS 7 跑一遍类型检查，允许失败但产出报告。这一步不阻塞合入，只是持续收集差异。

# CI 中的并行检查任务（示例）
- name: Type check (TS 7 preview)
  run: npx tsc --noEmit
  continue-on-error: true

第 3 步：按目录分批解锁

把第 2 步收集到的错误按目录归类，从”叶子模块”（依赖最少的工具层、类型定义层）开始修，逐步向业务层推进。这样每修一批都能立刻看到错误总数下降，进度可控。

第 4 步：切换默认版本并锁定

全部绿灯后，把 typescript 依赖切到 7.x 并锁定次版本，同时更新编辑器使用的 TS 版本（VS Code 需要在工作区里显式指定，否则可能仍在用内置版本）。

// .vscode/settings.json
{
  "typescript.tsdk": "node_modules/typescript/lib"
}

五、什么时候不该急着升

说了这么多好处，也得讲清边界。下面三种情况，建议再等一两个小版本：

• 强依赖内部编译器 API 的自研工具链：替代方案没落地之前，升级等于自断一臂；
• 处于发布冻结期的项目：类型检查行为变化可能牵出运行时问题，不值得在冻结期冒险；
• 装饰器重度使用且缺少回归测试：没有测试兜底，差异很难被及时发现。

反过来说，纯业务代码、测试覆盖尚可、CI 有类型检查关卡的项目，升级收益明显大于风险，可以排上日程。

六、小结

TypeScript 7 的价值不在新语法糖，而在把类型检查从”不得不忍受的等待”变成”随手可跑的即时反馈”。真正的工作量不在改代码，而在排查工具链依赖——尤其那些悄悄用了编译器内部 API 的插件。

迁移的正确姿势是并行跑、分批修、可回退，而不是挑个周末一把梭。