TypeScript 7.0 正式发布

2026 年 7 月 8 日，TypeScript 7.0 正式发布。它最大的变化不是新增一批类型语法，而是把编译器和语言服务迁移到 Go 原生实现：官方在多个大型开源项目上测得完整构建提速约 8～12 倍。与此同时，7.0 将 6.0 中弃用的配置提升为错误，升级需要先处理工具链兼容性。

一览：这次更新解决了什么

参考来源：Announcing TypeScript 7.0

TypeScript 7.0 采用 Go 重写核心工具链，利用原生执行、共享内存多线程与新的优化路径提升 tsc 和语言服务性能。官方表示，它尽量保持旧实现的结构和行为，以保证两套编译器的结果一致；因此，这是一轮以性能和工程容量为主的主版本更新。

官方基准数据如下。实际增益会受项目依赖图、CPU 核心数和 CI 资源限制影响，不应直接套用到单个仓库。

项目	TypeScript 6	TypeScript 7	构建加速
VS Code	125.7s	10.6s	11.9×
Sentry	139.8s	15.7s	8.9×
Bluesky	24.3s	2.8s	8.7×
Playwright	12.8s	1.47s	8.7×
tldraw	11.2s	1.46s	7.7×

同一组测试里，累计内存使用下降约 6%～26%；VS Code 代码库中，打开带错误文件到出现首个诊断的时间从约 17.5 秒降至 1.3 秒以内。大型 monorepo、频繁跑全量类型检查的 CI，以及依赖语言服务的编辑器是优先受益者。

编译阶段支持并行控制

参考来源：Announcing TypeScript 7.0 — Custom Scaling: Parallelization and Controls

解析、类型检查和 emit 可以并行执行。7.0 新增三个实验性命令行参数，用于在吞吐量与内存占用之间取舍：

参数	用途	使用要点
--checkers <n>	设置类型检查 worker 数	默认值为 4；增加 worker 可能加快大仓库，但会增加内存占用。
--builders <n>	设置 --build 下并行项目构建数	适合项目引用较多的 monorepo；与 --checkers 的资源消耗叠加。
--singleThreaded	禁用并行执行	适合性能对比、排障或资源很紧张的环境。

例如，tsc -b --checkers 4 --builders 4 最多可能同时运行 16 个类型检查 worker。CI 不能只按核心数盲目调高：内存受限的 runner 可先固定为较小值，并用真实项目的构建时间与峰值内存做比较。不同 --checkers 数量在极少数依赖检查顺序的项目中可能暴露不同结果，团队应在本地和 CI 固定同一配置。

--watch 与编辑器响应更快

参考来源：Announcing TypeScript 7.0 — Improved --watch Mode

tsc --watch 的文件监听基础设施被重建，基于 Parcel watcher 的移植实现，目标是在跨平台场景下避免纯轮询对大型 node_modules 的额外负担。日常开发无需增加配置；需要验证的是现有的 watch 脚本、容器挂载目录和网络文件系统是否仍能按预期收到变更事件。

编辑器端则改为以 Language Server Protocol 为基础，并可并行处理请求。VS Code 可通过 TypeScript 7 专用扩展启用，必要时用命令面板的 “Disable TypeScript 7 Language Server” 回退至 TypeScript 6。升级编辑器插件前，应先确认团队使用的语言服务插件是否依赖 TypeScript 的程序化 API。

迁移重点：7.0 会强制执行 6.0 的弃用项

参考来源：Announcing TypeScript 7.0 — Updates Since 5.x, and New Behaviors from 6.0

7.0 的类型检查和命令行行为以 6.0 为基线：已经能在开启 stableTypeOrdering、且不配置 ignoreDeprecations 的 TypeScript 6 项目上通过的代码，原则上应得到一致结果。风险主要来自仍停留在 5.x 行为或尚未清理 6.0 弃用警告的项目。

以下配置变化最容易影响构建产物和全局类型：

• rootDir 默认改为 ./。tsconfig.json 位于 src 之外的项目应显式设置 "rootDir": "./src"，避免声明文件或编译输出目录结构改变。
• types 默认变为 []。依赖 Node、Jest 等全局声明时，需要显式填写 "types": ["node", "jest"]；如需暂时恢复旧的自动包含行为，可设为 ["*"]。
• strict 默认开启，module 默认为 esnext，target 默认为紧邻 esnext 的当前稳定 ECMAScript 版本；noUncheckedSideEffectImports 默认开启，libReplacement 默认关闭。

下列项目在 6.0 中已弃用，7.0 会报硬错误：target: "es5"、downlevelIteration、moduleResolution: "node"/"node10"/"classic"、module: "amd"/"umd"/"systemjs"/"none"、baseUrl，以及将 esModuleInterop、allowSyntheticDefaultImports、alwaysStrict 显式设为 false。现代应用通常应转向 moduleResolution: "bundler" 或 "nodenext"，并使用 esnext 或 preserve 模块输出；路径别名需要改为相对项目根目录的 paths 映射。

另外，导入属性必须从 assert 改为 with，例如：

import data from "./data.json" with { type: "json" };

命令行在当前目录已有 tsconfig.json 时，不能再直接传入文件路径；确有需要时必须明确传 --ignoreConfig。这类问题适合在升级前用 npx tsc --showConfig 和完整 CI 类型检查先行发现。

模板字面量类型按 Unicode 码点推断

参考来源：Announcing TypeScript 7.0 — Template Literal Types Now Preserve Unicode Code Points

模板字面量类型中的 infer 现在会把 emoji 等 Unicode 字符按完整码点处理，而不是拆成 UTF-16 代理对：

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"😀abc">;
// TypeScript 7: ["😀", "abc"]
// 旧行为: ["\ud83d", "\ude00abc"]

这使行为更接近 for...of 和 [...str]。但若类型体操有意以 UTF-16 code unit 计算字符串长度或切片，结果会改变，应为 emoji、增补平面字符和代理对补充类型测试。

JavaScript + JSDoc 的宽松写法被收紧

参考来源：Announcing TypeScript 7.0 — JavaScript Differences

7.0 调整了 .js 文件的分析方式，使其更接近 .ts。常见不兼容写法包括：把值直接放在类型位置（改用 typeof value）、依赖 @enum 特殊识别、单独用 ? 表示类型、用 @class 把函数当构造器，以及 Closure 风格的 function(string): void 注解。纯 TypeScript 仓库通常不受影响；开启 checkJs 或维护 JSDoc 类型的库需要将这些写法纳入升级检查。

没有稳定 API，嵌入式工具链需要并行运行

参考来源：Announcing TypeScript 7.0 — Running Side-by-Side with TypeScript 6.0

7.0 不提供稳定的程序化 API，官方预计在 7.1 提供新的 API。因此依赖编译器 API 的工具（例如 typescript-eslint），以及把 TypeScript 嵌入自身编译或语言服务的 Vue、MDX、Astro、Svelte、Angular 模板检查等工作流，可能暂时不能完全切换到 7.0。

官方提供 @typescript/typescript6 兼容包：它暴露 tsc6，并重新导出 TypeScript 6 的 API。需要保持工具链可用时，可让依赖 API 的工具继续解析 typescript（6.0），同时为 7.0 加一个别名，以 npx tsc 获得新的原生命令行：

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

这不是长期双版本策略，而是等待工具升级的过渡方案。纯 tsc 项目可以直接安装 typescript；依赖编译器 API 或 embedded language 的项目应先确认上游兼容声明，再升级。

推荐升级顺序

1. 先将项目升级到 TypeScript 6，开启 stableTypeOrdering，删除所有 ignoreDeprecations，处理配置警告。
2. 明确 rootDir、types、模块解析策略和输出模块格式，并在 CI 运行一次全量类型检查。
3. 安装 TypeScript 7：npm install -D typescript，再执行 npx tsc --showConfig 检查最终配置。
4. 为类型体操、JSDoc 和项目引用构建补充回归测试；需要时固定 --checkers、--builders 的值。
5. 若项目依赖 typescript-eslint、Volar 或其他编译器 API 使用方，保留 TypeScript 6 的兼容包，待其宣布支持 7.0/7.1 后再收敛到单版本。

TypeScript 7.0 的价值集中在反馈速度和大规模工程的等待时间，而不是要求所有项目立即替换工具链。能够通过 TypeScript 6 基线检查的纯 TypeScript 项目可优先升级；嵌入式语言和深度集成编译器 API 的项目，应把兼容性验证放在性能测试之前。