TypeScript 7 升级决策：并行检查器、观察模式与 API 缺口
从 TypeScript 6 升级到原生支持 Go 的 TypeScript 7 时会有哪些变化，新的并行性标志如何运作，以及哪些工具链应在升级前暂缓操作。
TypeScript 7是一次与众不同的大版本更新：你编写的代码本身保持不变，但用于检查与编译它的工具却已被替换。对大多数团队而言，这次升级能显著提升效率且无需进行任何修改，但对于那些工具直接与编译器交互的团队来说，则可能成为障碍。本指南将说明6版与7版之间究竟存在哪些差异、如何使用新的并行性控制功能，以及如何判断项目是应该立即升级还是等待下一个版本发布。
该博客已经详细介绍了通过Go语言重写所带来的性能提升，也解释了为何这次移植会破坏代码检查工具和框架相关工具的功能，因此此处重点讨论实际的升级决策问题。
相同的语言，新的引擎
在撰写本文时，TypeScript 7.0 已作为稳定版本发布（据报道时间为2026年7月8日；可查看发行说明了解最新状态）。该版本是对编译器的重写，将原本用TypeScript编写的编译器改用Go语言实现，这是微软在2025年3月以Corsa为代号宣布的项目。它并非传统意义上的新语言版本：没有新的语法，类型系统的语义也保持不变，现有的
为何需要重写编译器
在TypeScript 6及之前版本中，编译器是用TypeScript编写的，并在JavaScript引擎上运行，实际上这意味着类型检查只能通过单线程完成。在那些规模较大的单体项目中，这一问题会以三种常见方式表现出来：
- 编辑器加载项目的速度极慢，开发者们不得不学会耐心等待。
- CI环境中的类型检查每次运行都需要数分钟时间。
- 内存占用量过高，导致笔记本电脑运行明显变得吃力。
该团队多年来一直在优化JavaScript实现方案，最终发现瓶颈在于运行时环境本身而非算法。于是他们将检查工具移植到了Go语言中，并刻意保持其结构与现有代码尽可能接近。这一选择至关重要：只有忠实移植而非重新设计，才能将6版本与7版本之间的行为差异控制在较小范围内。
实际应用中的不同之处
速度大幅提升的类型检查
微软公布的测试数据展示了改进的程度：VS Code代码库的类型检查时间从77.8秒缩短至7.5秒，速度提升了约十倍；Playwright的类型检查时间则从11.1秒降至1.1秒。这一成果得益于两个因素的结合：编译器现在以原生机器代码形式运行，而非由引擎执行的JavaScript；同时它还能利用goroutine并行进行类型检查，而旧的单线程设计根本无法做到这一点。实际效果会因项目结构不同而有所差异；许多小型独立文件比一大堆相互关联的类型定义更易于实现并行处理。
用于控制并行的新命令行选项
您的tsconfig.json文件无需更改，因为它描述的是语言和项目本身，而非编译器的工作调度方式。以下配置对两个版本都有效：
// tsconfig.json — nothing changes here, this is the language, not the compiler
{
"compilerOptions": {
"strict": true,
"target": "ES2022"
}
}
新的控制选项位于命令行中。--checkers用于设置并行运行的类型检查器数量，--builders控制同时进行的项目引用构建数量，而--singleThreaded则完全关闭并行处理：
# But at the CLI level, TypeScript 7 gives you real knobs to turn:
tsc --checkers 4 # number of parallel type-checker workers
tsc --builders 2 # parallel project-reference builds
tsc --singleThreaded # opt out entirely, useful for reproducible CI logs
当需要确定性强、易于阅读的持续集成日志，或正在排查潜在的顺序问题时，单线程模式非常有用。在共享的持续集成服务器上，将--checkers的值限制在可用核心数之内可以避免过度占用机器资源；同时运行的检查器越多，占用的内存也就越大，因此应根据实际情况进行调整，而非盲目追求最大值。
改进后的监控模式
在大型项目中，传统的基于轮询的文件监控机制存在明显缺陷，tsc --watch 无法及时响应文件修改。TypeScript 7 将 Parcel 所使用的文件监控机制移植到了 Go 语言中，因此保存文件后能立即重新编译，而不会再出现延迟。
更简单的打包流程
在预览阶段，使用原生编译器需要额外安装 @typescript/native-preview 包。而在 7.0 版本中，所有功能都回归到标准包名下，安装方式与以往完全一致：
npm install -D typescript
如果您曾试用过预览版本，请移除那个额外的包以及调用其独立二进制文件的脚本，以避免同时运行两个编译器。
真正的差距：编程接口
这部分内容决定了许多升级的可行性。基于 TypeScript 编译器 API 构建的工具，如语言服务插件、自定义代码检查规则以及 codemods，目前还无法依赖 Go 编译器 7.0 版本中稳定的编程 API；据目前了解，这一功能预计会在后续版本中推出，目标版本为 7.1。如果您的开发流程使用了类似 ts.createProgram() 的方法来分析程序结构，那么在正式环境中启用该功能之前，请务必仔细测试相关路径。
现实的迁移方案
想象一个中等规模的 Next.js 单体仓库，其中包含约 40,000 行 TypeScript 代码以及多个项目引用。在这样的环境中升级到 7.0 后，使用 tsc --noEmit 的编译时间可从大约 52 秒缩短至约 6 秒。单次提速 46 秒看似微不足道，但这一优势会体现在每一次 CI 流水线任务、每个预提交钩子以及调试时的手动检查中，整个团队每周因此可节省数小时时间。
对于那些仅使用 tsc 进行代码检查和构建的项目来说，升级过程往往显得平淡无奇：只需更新对应包，运行检查工具，确认在未修改代码的情况下测试通过即可。
npm install -D typescript@latest
npx tsc --noEmit # ran clean, zero code changes needed
干净无错误的编译结果是预期结果，而非绝对保证。建议保留 TypeScript 6 版本的编译结果以作对比，并在首次运行时详细记录报错信息，因为如此大规模的代码库中总可能出现一些边缘情况。
现在就应该升级吗？
- 如果您仅将
tsc用于类型检查与构建，那么请立即升级。这实际上是一种无需额外调整即可实现的改进。 - 如果您依赖编译器的编程 API 来开发自定义工具、编辑器插件或代码模块，那么请选择等待或分开使用：要么等待稳定版本的 API 出现，要么在运行类型检查时使用 7 版，同时为那些工具保留 6 版的 TypeScript。
- 如果您管理着规模极大的单仓库项目，且 CI 流水线的运行时间成本很高，那么请优先处理升级——节省下来的时间可在几天内抵消升级所需的精力。
核心要点
- TypeScript 7 改变的是编译器本身，而非语言本身；您的
tsconfig.json文件及源代码均可直接沿用。 - 性能提升得益于原生代码的运用以及并行检查机制，您可以通过
--checkers、--builders和--singleThreaded参数来调整相关设置。