TypeScript 7.0 迁移决策树：8 到 12 倍提速是真的，但你的项目可能暂时升不了

TypeScript 7.0 在 2026 年 7 月 8 日正式发布，编译器核心从 TypeScript 自己写自己、跑在 Node.js 上，换成了 Go 原生实现。微软公布的全量构建基准显示，VS Code 从 125.7 秒降到 10.6 秒，五个选定项目的加速比在 7.7 倍到 11.9 倍之间。小项目体感有限，但大型 monorepo 里“改一行等十几秒才出报错”的体验会明显改变。

提速的来源是原生代码执行加共享内存并行，而不是类型检查算法的突破。这意味着速度收益和项目规模强相关：几秒就能编完的小项目，升级后可能感觉不到差异；真正受益的是那些 CI 里 tsc --noEmit 要跑几分钟、编辑器诊断刷新要等半天的仓库。

但 7.0 不是一个无缝升级。它移除了一批旧配置：target: es5 被删除，最低目标抬到 es2015；moduleResolution 的 node 和 classic 被移除，需要迁移到 bundler、node16 或 nodenext；module 的 amd、umd、systemjs、none 被移除；baseUrl 被移除，绝对路径别名需要改用其他方式。更关键的是，7.0 暂不包含 6.0 里的程序化编译器 API，依赖 TypeScript API 做自定义构建、ESLint 插件或代码生成工具的项目需要等 7.1 或更高版本。使用 Vue、Svelte、Astro、MDX 这类“模板里嵌 TS”的框架，也要确认框架侧的兼容版本是否已经跟上。

一个可操作的决策树是这样的。如果你的项目是个人练习、新项目、没有依赖 TypeScript 程序化 API、没有用模板嵌 TS 的框架，现在就可以升，收益直接、风险低。如果项目用了 es5 目标或旧的 moduleResolution，先完成配置迁移再升级，不要指望 7.0 静默兼容。如果项目依赖 TypeScript API 做构建工具或自定义 lint 规则，等程序化 API 发布后再评估；在此之前升级会直接破坏工具链。如果项目用 Vue/Svelte/Astro/MDX，先查框架的官方兼容说明，框架侧的升级节奏通常比编译器慢一个版本。公司核心业务的最佳窗口不是“7.0 发布时”，而是“你的构建工具、lint 插件、框架集成都发布了兼容版本之后”。

速度收益是真实的，但它不是升级的唯一变量。编译器重写带来的破坏性变更，以及生态跟进的延迟，决定了大多数生产项目在 7.0 发布后的几个月内更合理的策略是“先在边缘项目验证，等核心依赖跟上再迁主干”。