TypeScript 7.0 RC发布：Go重写编译器，性能提升10倍

微软6月18日发布TypeScript 7.0 RC，编译器核心从TS自举改为Go重写，VS Code代码库类型检查从77.8秒降到7.5秒，内存减半，语义与6.0完全兼容。

微软昨天（6月18日）扔出了 TypeScript 7.0 的 RC 版。这次更新没什么花哨的新语法、新类型操作符，主菜只有一道——编译器底层从 TypeScript 自举改成了 Go 重写，平均编译和类型检查速度提升约 10 倍，内存占用大致减半。

这是 TypeScript 自 2012 年发布以来 14 年里最伤筋动骨的一次重构。把自己用的语言换掉、还要保证语义一模一样，这事在编译器圈里少有人干，干成的更少。

TypeScript 7.0 RC 性能对比图，Go 重写版 vs JS 版编译耗时柱状图

不是优化，是重写

先把背景捋清楚。TypeScript 团队从 2025 年 3 月就放出了风声，代号 Corsa，由 Anders Hejlsberg 亲自下场带队——这位老爷子的履历不用多介绍，Turbo Pascal、Delphi、C#、TypeScript 都是他主导的。他选 Go 而不是 Rust、C++ 或者 C#，当时也引发了不小的争论，Rust 社区一度颇有微词。

团队给出的解释很务实：Go 的语义和现有 TypeScript 代码非常接近，逐行翻译的成本最低；GC 模型省心；并发原语原生支持；交叉编译方便。他们要在尽量短的时间内把十几万行 TS 编译器代码搬过去，并且保证测试套件全绿——这种场景下，Rust 的所有权模型反而成了负担。

这次的 7.0 RC 就是这条路线的兑现版本。官方明确说了，移植是逐行翻译的，没有趁机改架构、没顺手优化算法、连变量命名都尽量贴着原来。这么做有一个非常重要的好处：语义稳定。十年积累的回归测试一个都没动，全部通过，意味着升级到 7.0 理论上不会有任何行为变化。这种工程纪律在大厂里也不常见。

性能数据，老老实实给

微软这次没玩文字游戏，性能数字给的是真实项目的真实数据：

| 项目 | 代码规模 | 6.0 耗时 | 7.0 耗时 | 提升倍数 | |------|---------|---------|---------|---------| | VS Code | 150 万行 | 77.8s | 7.5s | 10.4x | | Sentry | - | 133s | 16s | 8.2x | | TypeORM | 27 万行 | 17.5s | 1.3s | 13.5x | | Playwright | 35.6 万行 | 11.1s | 1.1s | 10.1x | | rxjs | 2.1k 行 | 1.1s | 0.1s | 11x |

注意几个细节：第一，这些不是 hello world 级别的测试用例，VS Code 自己就是 150 万行代码量级的庞然大物；第二，TypeORM 提升 13.5 倍是因为它用了大量复杂的泛型推断，原来的 JS 实现卡死在解释执行上；第三，小项目（rxjs 2.1k 行）也有 11 倍提升，说明加速不是只在大项目上有效。

官方给出的拆解是：约 50% 的加速来自原生代码（Go 编译成机器码 vs V8 解释/JIT），另外 50% 来自共享内存并行。这个分配挺关键——它说明仅仅"换语言"能拿到一半收益，剩下一半要靠真正改造执行模型。

并发：JS 拿不到的那一半

这里值得展开讲一下。TypeScript 编译器之前为什么不能多线程？因为它跑在 Node.js 上，Node 的 worker_threads 各自一套堆，共享数据要走序列化，对于类型检查这种"一张巨大的类型图谱反复遍历"的场景，序列化成本比单线程跑还高。所以六年来 TypeScript 一直是单核打天下，i9 16 核摆在面前也只能干瞪眼。

Go 不一样。Goroutine 共享内存、调度由 runtime 接管，类型检查阶段可以把不同模块、不同文件的检查并行分发，所有 worker 都直接读同一份 AST 和符号表，不用拷贝。这才是大项目（VS Code、Sentry 这种）能稳定拿到 10 倍提升的原因。

换句话说，这次重写真正解锁的是"TypeScript 能用多核了"，性能提升只是结果，不是目的。等机器从 8 核升到 32 核，理论上还能继续吃满。

LSP 重做，编辑器体验也变了

除了 tsc，配套的语言服务器也整个重做了。新的 LSP 实现支持多线程并发处理请求，意思是自动补全、跳转定义、悬停提示这些操作可以同时进行，不会因为后台在跑全量类型检查就把光标卡住。

VS Code 用户现在就能尝鲜，装个叫 TypeScript Native Preview 的扩展即可。这个扩展已经接入了：

自动导入（auto-import）
悬停提示（hover）
内嵌提示（inlay hints）
代码透镜（code lens）
重命名、查找引用等常规功能

微软还顺手提了一个有意思的数据：模糊测试（fuzzing）下，语言服务器命令的失败率降到了 6.0 版本的 1/20。这说明 Go 重写不只是快，稳定性也实打实地上了一个台阶。Go 的强类型 + 编译期检查在这种工程量的代码里确实比 TypeScript 自己更扛揍。

完全兼容 6.0，但 6.x 还会继续维护

升级路径上，微软的态度比较克制。

7.0 在语义上完全兼容 6.0，理论上改一下 tsconfig 的引用就能切。但官方也明确说了，6.x 系列会继续维护——原因是部分项目依赖了编译器的内部 API，比如 ts-loader、babel-plugin、ESLint 的 typescript-eslint 等等。这些工具直接调 TypeScript 暴露的 JS API，Go 重写版的 API 表面不可能 100% 复刻。

所以未来一段时间里会出现这样的格局：

TypeScript 6.x（JS 版）：继续维护，给那些重度依赖编译器 API 的工具链兜底
TypeScript 7.x（Go 原生版）：主推方向，性能为王，普通业务项目优先升级

对开发者来说，最现实的影响是：如果你的项目就是写写业务代码、用 webpack/vite 打包，那基本可以直接升 7.0，CI 时间可能从几分钟掉到几十秒。但如果你写了自定义的 TypeScript transformer 或者用了 ts-morph 之类操作 AST 的工具，得等生态跟上。

一些值得说的判断

这事放在更大的视角看，有几层含义。

第一，前端工具链"原生化"的趋势又被推了一把。 esbuild（Go）、SWC（Rust）、Turbopack（Rust）、Biome（Rust）、Oxc（Rust）……过去三年前端工具链基本被原生语言重写了一遍，剩下的最后一个大头就是 TypeScript 编译器本身。现在这块也倒下了，意味着 Node.js 跑工具链的时代正在加速结束。未来新项目搭建的时候，开发者会越来越习惯于"工具链都不是 JS 写的"这件事。

第二，Anders Hejlsberg 选 Go 而不是 Rust 是个值得复盘的决策。 当初这个决定被骂了不少，但回头看，项目能在一年多时间内把 RC 拿出来、还能保持语义一致，Go 在这种"翻译式重写"场景下的生产力确实是 Rust 比不了的。Rust 适合从零设计的新项目，Go 适合大规模迁移老项目，这次是个教科书级别的案例。

第三，TypeScript 终于解决了"大项目越用越慢"的死结。 之前不少超大型项目（Slack、Airbnb、Stripe 都有公开抱怨）卡在类型检查上，CI 跑十几二十分钟是常态，开发体验崩溃。现在 10 倍提升把这个问题硬性消化掉了，TypeScript 在超大代码库的竞争力会重新拉开和 JSDoc + JS 这种"轻量方案"的差距。

第四，对国内开发者特别值得注意的是：Go 编译产物是单一二进制，分发起来比 npm install 一堆依赖要清爽得多。CI 里直接拉一个 tsc 二进制就能跑，对自建 CI、对 Monorepo、对 Docker 镜像体积都是好消息。

怎么试

现在想试的话，两条路：

# 1. 装 TypeScript Native Preview 扩展（VS Code）
# 在扩展市场搜 \"TypeScript Native Preview\" 即可

# 2. 直接跑命令行版
npm install -D @typescript/native-preview
npx tsgo --version
npx tsgo -p tsconfig.json

注意命令叫 tsgo 而不是 tsc，是为了避免和现有安装冲突。配置文件、tsconfig.json 都不用改。

微软给的时间表是 正式版预计在 2026 年下半年，RC 之后还会有几轮迭代。从过往 TypeScript 的发布节奏看，RC 阶段一般 2 到 3 个月，正式 GA 大概在 9 月到 10 月之间。

这是 TypeScript 14 年来最大的一次变化，也是前端工具链原生化运动里最重的一块石头落地。下一个值得期待的，可能就是 Node.js 自己什么时候把 TypeScript 支持做进 runtime 了——现在 Deno 和 Bun 已经走在前面，Node 24 刚加了 type stripping，但完整类型检查还得靠外部。

等 7.0 GA，这场仗的格局可能又要重排一次。