TypeScript 7.0 RC：这次是真的 typescript@rc，不只是 tsgo
本文基于 TypeScript 7.0 RC（2026-06-18 发布）撰写。重点是：Go 原生编译器已经从预览阶段的
tsgo正式走进typescript@rc发布通道，当前版本7.0.1-rc。
引言
TypeScript 7 的消息已经传了很久，但之前大多数人的注意力都在 tsgo 这个实验代号上。2026 年 6 月 18 日，微软把 Go 原生编译器正式放进了 typescript@rc 通道------这意味着它不再是旁路预览包，而是接替 tsc 的下一个主版本。
如果你在过去几年里维护过大型 TypeScript 项目，应该熟悉这些场景：
- 本地保存文件后，VS Code 的 TypeScript 状态栏要转好几秒才出类型错误；
- CI 里的
tsc --noEmit动辄跑上一两分钟，成为整个流水线里最慢的一环； - 打开一个百万行级别的 monorepo，语言服务初始化就要喝一口咖啡。
这些痛点的根源是旧版编译器用 TypeScript 自举，再编译成 JavaScript 跑在 Node.js 上。随着项目规模变大，JS 运行时的解释开销和单线程模型逐渐成为瓶颈。
2025 年 3 月，微软 TypeScript 团队首次披露了 Project Corsa ：把编译器和语言服务整体移植到 Go。一年三个月后，TypeScript 7.0 RC 发布，Go 原生编译器终于以 typescript@rc 的形式走到了普通开发者面前。
为什么选 Go？
这个问题在公布之初就引发了很多讨论。大家原本猜测的可能是 Rust 或 C++，结果微软选了 Go。
按照官方的解释，核心原因是工程效率与可移植性的平衡：
- Rust 性能更强，但完全重写需要更长时间，维护门槛也更高；
- C/C++ 同样快，但内存安全和跨平台构建会让团队付出额外成本；
- Go 编译速度快、并发模型简单、跨平台构建成熟，同时性能足够支撑原生编译器的需求。
更关键的一点是：这次不是"重写"，而是有组织的移植。团队尽量保持类型检查逻辑的结构与旧版一致，从而保证语义一致，而不是重新发明一套编译器。
性能提升到底有多大？
官方公布的数字非常夸张，但确实是真实项目跑出来的结果：
| 代码库 | TS 6（旧 tsc） | TS 7（typescript@rc 的 Go 原生 tsc） |
提速 |
|---|---|---|---|
| VS Code（约 150 万行） | 77.8s | 7.5s | ~10x |
| Playwright | 11.1s | 1.1s | ~10x |
| TypeORM | 17.5s | 1.3s | ~13x |
除了全量类型检查，编辑器冷启动提升也很明显：VS Code 项目加载从 9.6 秒降到 1.2 秒左右。内存占用大约减少一半。对于大型 monorepo 来说，这意味着开发反馈循环和 CI 成本都会有显著改善。
如何尝鲜？重点：直接装 typescript@rc
TypeScript 7.0 RC 已经可以通过 typescript@rc 标签安装：
bash
npm install -D typescript@rc
npx tsc --version # Version 7.0.1-rc关键变化 ：从 RC 开始，Go 原生编译器不再以 tsgo 这个旁路命令存在，而是直接接管 tsc。你平时怎么调用 tsc，现在还怎么调用，只是它底下已经换成了 Go 实现。
如果你之前追的是 nightly 预览包，习惯用的是 tsgo，现在需要区分两条线：
| 场景 | 安装命令 | 可执行文件 |
|---|---|---|
| RC 正式通道 | npm install -D typescript@rc |
tsc |
| Nightly 预览通道 | npm install -D @typescript/native-preview |
tsgo |
也就是说，日常项目尝鲜请直接用 typescript@rc，不要再把 tsgo 当作 TS7 的代名词。
编辑器端可以安装 VS Code 的 TypeScript Native Preview 扩展，然后在设置中开启：
json
"typescript.experimental.useTsgo": true并行化与新参数
TypeScript 7.0 利用共享内存并行处理解析、类型检查和 emit。其中类型检查的并行度可以通过 --checkers 控制：
bash
npx tsc --checkers 8默认值是 4。核心数更多的机器可以适当调高，但内存占用也会随之增加；CI 等内存受限环境则可能需要调低。
迁移前需要知道的事
虽然 RC 已经非常接近生产可用，但仍有几个关键点需要考虑：
-
程序化 API 还不稳定
官方表示稳定 API 要等到 TypeScript 7.1 。依赖
typescript包内部 API 的工具链------例如typescript-eslint、ts-morph、ts-node的某些用法------还不能直接迁移。 -
可以并行安装 TS6 和 TS7
微软发布了兼容包
@typescript/typescript6，提供tsc6命令，方便与 TS7 的tsc共存：bashnpm i -D typescript@npm:@typescript/typescript6 -
建议先对比再切换
在 CI 里同时跑 TS6 的
tsc --noEmit和 TS7 的tsc --noEmit，确认错误、输出行為一致后再正式切换。 -
生产环境仍建议等 GA
RC 适合日常开发和 CI 实验，关键生产发布最好等正式版。
对前端生态的影响
TypeScript 7.0 的速度提升会重塑很多工作流：
- 编辑器体验：大型项目的语言服务启动和补全响应会明显变快；
- CI 成本：类型检查阶段大幅缩短，Runner 等待时间减少；
- 工具链分层：类型检查（tsc）和转译（esbuild、SWC、Rolldown）的职责会更加清晰，tsc 终于不再因为慢而被绕开。
结语：重点是 typescript@rc
TypeScript 7.0 不是一次普通的大版本更新，而是整个工具链底层运行时的替换。过去几年大家传的是"TS7"和"tsgo"，但真正值得关注的节点是 2026 年 6 月 18 日 Go 原生编译器进入 typescript@rc 通道。
从这一刻起，TS7 不再是一个实验代号，而是可以通过 npm install -D typescript@rc 直接安装的下一个主版本。tsgo 完成了它的历史使命：把预览验证做扎实；接下去的接力棒交给了 tsc。
对于普通开发者来说，最直接的收益就是"类型检查不再拖慢开发节奏"。如果你还没试过，现在就是最好的时机：
bash
npm install -D typescript@rc然后跑一遍你项目的类型检查，感受一下 10 倍提速是什么体验。