今天跟大家聊一个前端圈的大事：TypeScript v7.0 正式发布。

说实话，这个版本不是普通迭代，而是 TS 团队憋了一年多的大招。核心就一句话：用 Go 重写的原生 TypeScript，编译速度最高能快 10 倍以上。

天下苦 tsc 慢久矣，这次终于要翻身了。

缘起：TS 为什么慢？

咱们先别急着看成绩，先想想一个问题：TypeScript 到底慢在哪？

日常开发中，你打开 VS Code，打开一个 .ts 文件，等类型提示出来要时间。你改一行代码，等红色波浪线更新要时间。你跑 tsc 构建，等完整编译更要时间。

在大型项目里，这些等待不是几秒钟，而是几十秒甚至几分钟。

TS 团队也清楚这个问题。去年他们就预告过，要用 Go 把 TypeScript 重写一遍。不是小修小补，是整锅端掉、重新做。

现在，TypeScript 7.0 就是这个计划的正式落地。

它到底快了多少？

官方给了一个很醒目的数字：总体构建速度提升 8 到 12 倍。

几个大厂开源项目的实测数据也很能说明问题：

更夸张的是编辑体验。

在 VS Code 的代码库里，打开一个文件到第一个错误显示出来，之前要 17.5 秒，现在只要 1.3 秒，快了 13 倍。

内存占用也下来了。根据官方数据，整体内存使用普遍降低 6% 到 26%。

也就是说，TS 7 不仅更快，还更省资源。

为什么能快这么多？

核心原因有两个：Go 原生编译 + 多线程并行。

原来的 TS 编译器跑在 Node.js 上，是解释执行加单线程模型。项目一大，就只能排队处理。

TS 7 用 Go 重写后，变成了原生机器码。同时它利用了现代 CPU 的多核能力，把解析、类型检查、代码生成这些步骤尽量并行化。

官方透露，Go 版本的代码结构和逻辑尽量忠实于原来的 TS 实现。也就是说，语法、类型行为、错误提示这些尽量保持一致，主要区别在运行层面。

这个策略很聪明：既保留生态熟悉度，又从根上解决性能问题。

多线程怎么控制？

TS 7 引入了几个新的命令行参数，让你可以自己调并行度。

--checkers

控制类型检查的并行 worker 数量，默认是 4。

代码库够大、机器核够多，可以调高这个值。但内存会涨，要自己平衡。

--builders

控制项目引用构建的并行度。对 monorepo 项目特别有用。

它和 --checkers 是乘法关系。比如 --checkers 4 --builders 4 最多可以跑出 16 个类型检查器同时跑，小项目别乱开，会爆内存。

--singleThreaded

一键关闭所有并行，变成单线程模式。调试、对比性能、或者机器资源紧张的时候用得上。

--watch 模式也重写了

这次 --watch 模式不是小升级，是直接换了个底层实现。

TS 7 的文件监听基于 Parcel 的 watcher 重新用 Go 写了一遍。跨平台更稳，大型项目的 node_modules 也不会像以前那样疯狂吃资源。

实际体验就是，保存文件后反馈更快，CPU 占用更低。

一些新的默认行为

TS 7 沿用了 TS 6 的很多新默认值，下面几个最可能影响你升级：

• strict 默认 true。
• module 默认 esnext。
• target 默认是 esnext 前一个稳定 ECMAScript 版本。
• rootDir 默认是 ./。
• types 默认是 []。

另外，一些老配置被彻底干掉了：

• target: es5 不再支持。
• moduleResolution: node / node10 不再支持，推荐用 bundler 或 nodenext。
• module: amd / umd / systemjs / none 不再支持。
• baseUrl 不再支持。
• downlevelIteration 被移除。
• esModuleInterop 和 allowSyntheticDefaultImports 不能设为 false。

如果你是从 TS 5 甚至更早版本直接跳过来的，升级前一定要先把 TS 6 的迁移文档看一遍。官方也建议先在 TS 6 上跑顺，再升级到 TS 7。

和 TypeScript 6 可以共存

这次官方想得比较周到，提供了 @typescript/typescript6 这个兼容包。

你可以把 TS 6 作为依赖别名安装，比如：

{
    "devDependencies": {
        "typescript": "npm:@typescript/typescript6@^6.0.2",
        "typescript-7": "npm:typescript@^7.0.2"
    }
}

这样 tsc6 用旧版 API，tsc 或 npx tsc 用新版。

为什么需要这个？因为很多工具链，比如 typescript-eslint，现在还需要 TS 6 的 API。TS 7 的程序化 API 要等到 7.1 才发布。

编辑器体验怎么样？

VS Code 用户可以装一个 TypeScript 7 的专用扩展。装上之后默认启用，不满意可以在命令面板里随时切回 TS 6。

据说再过几周，VS Code 会内置 TS 7 支持，不用单独装扩展。

Visual Studio 也会自动根据工作空间启用 TS 7。

其他编辑器也没问题，因为 TS 7 的语言服务基于 LSP，多线程响应请求。

不过要注意：Vue、MDX、Astro、Svelte 这些框架目前还用不了 TS 7。它们依赖 TS 的程序化 API，而 TS 7 的 API 还没开放。TS 团队说会跟这些项目维护者合作，后续解决。

大厂反馈怎么样？

官方列了一堆大厂的实测反馈，挑几个看看：

• Slack：CI 类型检查从 7.5 分钟 降到 1.25 分钟，合并队列时间少了 40%。
• Vanta：部分项目构建速度提升 9 倍。
• Microsoft News Services：每个月节省 400 小时 的 CI 等待时间。
• PowerBI 团队：直言 TS 7 编辑器体验是 “life-saving”。
• Canva：编辑器里首次显示错误从 58 秒 降到 4.8 秒。

这些数据不是实验室数据，是真实代码库上的结果。对于大型项目来说，TS 7 的吸引力非常强。

我的看法

说实话，TS 7 的发布是前端工具链的一个分水岭。

它不是加几个新语法、修几个 bug 的版本。它是把 TypeScript 从一个解释型工具，变成了一个原生编译器。这背后的投入和决心都不小。

对于个人项目，你可能感觉不到翻天覆地的变化。但如果你在一个几十万行代码的 monorepo 里干活，TS 7 可能就是救命的。

当然，升级也不是无脑冲。API 还没稳定、一些工具链还没适配，嵌入式语言框架暂时还用不了。建议先在小项目试试，跑顺了再考虑大面积迁移。

总结

TypeScript 7.0 核心就三件事：

• 用 Go 重写，原生速度。
• 多线程并行，充分利用现代 CPU。
• 编译速度提升 8 到 12 倍，内存还更低。

天下苦 tsc 慢久矣，这一次，TypeScript 终于自己革了自己的命。

如果你也在用 TypeScript，不妨抽时间升级试试，看看你的项目能快多少。