TypeScript 7.0 深度拆解：当微软用 Go 重写 TypeScript 编译器——8-12 倍性能飞跃的工程全貌（2026）

2026 年 7 月 8 日，微软正式发布 TypeScript 7.0。这不是一个常规的类型语法更新，而是一次彻底的底层架构迁移——整个 TypeScript 编译器和语言服务被从 TypeScript/JavaScript 重写为 Go 原生实现。这不是小打小闹的性能优化，而是 TypeScript 自 2012 年诞生以来最大幅度的一次「换心手术」。官方数据显示：VS Code（230 万行 TypeScript 代码）全量编译时间从 125.7 秒骤降至 10.6 秒，11.9 倍提速；Sentry 编译时间从 139.8 秒降至 15.7 秒，8.9 倍提速；Bluesky、Playwright、tldraw 等项目均有 7.7-8.7 倍不等的加速。

这不是一个关于「要不要升级」的问题，这是一个关于「编译器工程学」和「语言演进哲学」的深度案例。本文将从架构设计、性能数据、破坏性变更、迁移路径等维度，对 TypeScript 7.0 进行全面拆解。

一、背景：TypeScript 编译器为何需要「换心手术」

1.1 性能瓶颈的根源

TypeScript 编译器（tsc）自诞生以来，一直是用 TypeScript 本身编写的——这是一个自举（self-hosted）的编译器。这种设计在早期有其合理性：团队规模小，TypeScript 本身是团队最熟悉的语言，快速迭代比极致性能更重要。但随着 TypeScript 生态的爆炸式增长，问题逐渐暴露。

首先是内存开销。Node.js 运行时本身就是一个重量级进程，而 TypeScript 编译涉及大量的字符串操作、对象创建和垃圾回收。在大型 monorepo 中，一次全量编译可能占用数 GB 内存，且 GC 停顿会导致编译时间不可预测地抖动。

其次是并行化的天然限制。Node.js 的单线程 JavaScript 运行时无法充分利用现代多核 CPU。虽然 tsc 在某些阶段有一些内部并行，但整体架构是为单线程设计的。要实现真正的并行类型检查，需要在进程级别做大量协调工作。

第三是启动开销。每次运行 tsc 都需要启动一个完整的 Node.js 进程，冷启动时间在数百毫秒到数秒之间。对于大型项目，这意味着频繁的增量编译和 watch 模式下，编译器启动时间会成为不可忽视的瓶颈。

1.2 Go 语言为何成为选择

微软选择 Go 语言重写编译器，有几个深层原因：

第一，卓越的并发模型。 Go 的 goroutine + channel 模型天然适合编译器这种 IO 密集型且有大量并行化机会的场景。相比于手动管理线程池，Go 的调度器可以在数千个轻量级协程之间高效切换，这是 tsc 实现 --checkers 多 worker 并行类型检查的基础。

第二，卓越的部署体验。 Go 编译产物是一个静态链接的单一可执行文件，没有 Node.js 运行时依赖。对于一个命令行工具来说，这意味着安装即用，且二进制启动时间远低于 Node.js 进程启动时间。

第三，内存可控性。 Go 的垃圾回收虽然不如 JavaScript V8 那样激进针对短生命周期对象优化，但在编译这种批处理场景下，可预测的 GC 暂停和可控的内存上限更有利于 CI 优化。

第四，微软内部的技术积累。 Go 在微软内部已被大量采用（Dapr、Terraform Provider、Cilium 等项目），团队对 Go 的工程实践和性能调优有丰富经验。选择 Go 而非 Rust 或 C++，是一个在性能、团队生产力和交付速度之间取得平衡的务实决策。

1.3 重写策略：「高度还原」而非重新设计

微软此次重写的一个重要原则是「高度还原」（faithful translation），即尽量保持旧实现的结构和行为，确保两套编译器的结果一致。这不是一次编译器架构重新设计，而是一次语言移植。这意味着：

• 相同的类型检查规则
• 相同的语法解析行为
• 相同的代码生成输出
• 相同的 tsconfig.json 配置语义

这是一次以性能和工程容量为主要目标的版本更新，而非语言功能的革新。TypeScript 团队明确表示，未来新功能开发将在 Go 实现的基础上展开。

二、性能数据：8-12 倍提速的真实含义

2.1 官方基准测试数据

微软在公告中公布了一组官方基准测试数据，覆盖了不同规模和类型的项目：

这些数据令人印象深刻，但需要理性解读：

提速倍数的来源是多层叠加的：原生 Go 代码执行速度本身就比 Node.js JIT 编译后的 JavaScript 快；Go 的并行化让多核 CPU 得到充分利用；Go 编译器的启动时间远低于 Node.js；新的编译器优化路径减少了不必要的重复计算。

加速效果与项目特征强相关：项目越大、类型系统越复杂、依赖图越深，收益越明显。一个只有几百个文件的小项目可能感受不到明显差异，但一个数百万行的 monorepo 项目，每天的 CI 节省时间可能达到数十分钟甚至更多。

2.2 内存占用：下降 6%-26%

除了编译时间，另一个关键指标是内存占用。在上述项目中，累计内存使用量（peak memory across all workers）下降了 6%-26%。这主要得益于：

更高效的内存布局。Go 的 slice 和 map 数据结构在内存分配上比 JavaScript 对象更紧凑。TypeScript 编译器需要维护大量的类型信息、符号表和 AST 节点，内存布局的优化直接反映在整体占用上。

更精细的内存管理。Go 的 GC 虽然不如 V8 激进，但其行为更可预测。在批处理场景下，这意味着更少的 GC 暂停和更稳定的内存使用曲线。

2.3 首个诊断时间：17.5 秒降至 1.3 秒

对于日常开发体验来说，全量编译时间只是其中一个维度。更值得关注的是「首个诊断时间」（Time to First Diagnostic）——即从打开一个带错误的 TypeScript 文件，到编辑器中出现第一条红色下划线的时间。在 VS Code 代码库测试中，这个时间从约 17.5 秒降至 1.3 秒以内，提速超过 13 倍。

这意味着在 VS Code 中打开一个大型 TypeScript 文件时，错误提示几乎是即时的，而不是之前需要等待十几秒才能看到诊断结果。这对开发体验的改善是革命性的。

三、架构解析：Go 重写后的编译器长什么样

3.1 整体架构

TypeScript 7.0 的 Go 编译器在架构上保留了原有的模块划分，主要包括：

源码 → Scanner（词法分析）→ Parser（语法分析）→ Binder（绑定）
    → Program（程序构建）→ Checker（类型检查）→ Emitter（代码生成）

Go 版本对这些模块的实现进行了全面重构：

词法分析（Scanner）
Go 的 for range 迭代 rune 序列天然适合 Unicode 处理，配合 Go 1.21+ 的优化，字符串迭代性能大幅提升。UTF-8 到 UTF-16 的转换逻辑也得到了精简，减少了不必要的编码转换开销。

语法分析（Parser）
Go 的递归下降 parser 配合结构体组合，比 TypeScript 原版的 class-based parser 更高效。内存分配模式从对象 new 改为结构体值拷贝，减少了 GC 压力。

类型检查（Checker） — 这是性能提升的核心
TypeScript 类型系统极其复杂，包含泛型、条件类型、映射类型、模板字面量、递归类型等。Go 实现通过以下方式优化：

• 工作集局部性：利用 Go 的值类型语义，让类型信息尽量保持在 CPU cache 友好的内存布局中
• 增量缓存：符号表和类型信息支持增量更新，避免重复计算
• 并行类型检查：通过 --checkers 参数启动多个 goroutine worker 并行处理文件

3.2 并行控制：新增三个实验性参数

TypeScript 7.0 引入了三个新的命令行参数，用于精细控制并行行为：

# 设置类型检查 worker 数量（默认值为 4）
tsc --checkers 4

# 设置 --build 模式下并行构建的项目数
tsc -b --builders 4

# 完全禁用并行，执行单线程模式
tsc --singleThreaded

关于 --checkers 的实战建议：

• 默认值 4 对大多数机器是安全选择
• 增加 worker 数会提升 CPU 利用率，但同时增加内存占用
• n 个 worker 配合 m 个 builder 可能同时运行 n × m 个 goroutine，资源消耗是叠加的
• 在 CI 环境中不要盲目按 CPU 核心数设值，要先在真实环境中测量峰值内存和编译时间

// 示例：在 monorepo 根目录启用并行构建
// package.json 中的 CI 脚本
{
  "scripts": {
    "typecheck": "tsc --noEmit -b packages/*/tsconfig.json --checkers 4 --builders 4"
  }
}

3.3 Watch 基础设施重建

tsc --watch 的文件监听基础设施被完全重建，基于 Parcel watcher 的移植实现。这解决了原有实现中的一些痛点：

旧实现的问题：原有 watch 基于轮询或平台特定的 FSEvents/inotify。在大型 node_modules 目录或网络文件系统上，轮询会产生显著的性能开销，而 FSEvents 在某些情况下会遗漏文件变更事件。

新实现的目标：跨平台统一行为，减少对 node_modules 的额外扫描开销，提供更可靠的事件通知。

对于日常开发来说，这通常是透明的。但对于以下场景需要注意验证：

• 使用 Docker volume 挂载源代码目录
• 使用 NFS 或其他网络文件系统
• 使用特殊监控工具拦截文件系统事件

3.4 编辑器语言服务：LSP 并行化

编辑器端（语言服务）的架构也发生了重大变化：

从嵌入式到 LSP 化。新版编辑器语言服务基于 Language Server Protocol（LSP），支持并行处理多个 LSP 请求。这意味着：

• VS Code 可以同时处理多个文件的语义高亮、类型提示、错误诊断
• 诊断结果不再相互阻塞，编辑体验更流畅
• 通过 tsserver 独立进程（而非直接嵌入 VS Code 进程）提供语言服务，减少主进程负担

向后兼容：--disableTypeScript7LanguageServer 命令可以回退到 TypeScript 6 的语言服务，用于处理插件兼容性问题。

四、破坏性变更：升级前的必修课

TypeScript 7.0 对配置行为做了大量收紧。如果你还在使用陈旧的项目配置，升级到 7.0 后可能会遇到大量编译错误。以下是所有破坏性变更的完整清单。

4.1 默认配置调整

以下配置项的默认值在 7.0 中发生了重大变化：

// tsconfig.json 的默认值变化
{
  // 之前：默认从 tsconfig.json 所在目录推断
  // 现在：默认 "./"（当前目录）
  "rootDir": "./",

  // 之前：自动包含 @types/* 中的所有类型
  // 现在：默认 []（不自动包含任何 @types）
  "types": [],

  // 之前：非严格模式
  // 现在：默认开启 strict 模式
  "strict": true,

  // 之前：commonjs
  // 现在：esnext
  "module": "esnext",

  // 之前：无此选项
  // 现在：默认开启
  "noUncheckedSideEffectImports": true,

  // 之前：默认开启
  // 现在：默认关闭
  "libReplacement": false
}

rootDir 变化的典型问题：

// 旧配置（隐式依赖默认行为）
{
  "compilerOptions": {
    "outDir": "./dist"
    // rootDir 未显式设置，依赖 tsconfig.json 位置推断
  }
}

// 修复后
{
  "compilerOptions": {
    "outDir": "./dist",
    "rootDir": "./src"
  }
}

types 变化的典型问题：如果你的项目依赖 node、jest、@types/react 等全局类型定义，7.0 后需要在 tsconfig 中显式声明：

{
  "compilerOptions": {
    "types": ["node", "jest", "@testing-library/jest-dom"]
  }
}

或者，如果你需要恢复旧的自动包含行为：

{
  "compilerOptions": {
    "types": ["*"]
  }
}

4.2 弃用项升级为硬错误

以下在 TypeScript 6 中标记为弃用（deprecation warning）的配置项，在 7.0 中直接报错：

禁止使用的配置项：

// 以下配置直接报错，不提供过渡期
{
  "compilerOptions": {
    "target": "es5",              // ❌ 硬错误
    "downlevelIteration": true,    // ❌ 硬错误
    "moduleResolution": "node",   // ❌ 硬错误（改用 "bundler" 或 "nodenext"）
    "moduleResolution": "node10", // ❌ 硬错误
    "moduleResolution": "classic",// ❌ 硬错误
    "module": "amd",              // ❌ 硬错误
    "module": "umd",              // ❌ 硬错误
    "module": "systemjs",         // ❌ 硬错误
    "module": "none",             // ❌ 硬错误
    "baseUrl": ".",               // ❌ 硬错误
    "esModuleInterop": false,     // ❌ 硬错误
    "allowSyntheticDefaultImports": false // ❌ 硬错误
  }
}

正确的迁移路径：

// 现代配置示例
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strict": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "skipLibCheck": true
  }
}

关于 baseUrl 和路径别名的迁移：baseUrl 被移除后，路径别名需要改用 paths 映射：

// 旧配置
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

// 新配置（移除 baseUrl）
{
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

4.3 导入属性语法：assert → with

ES 规范已将 import assert 语法改为 import with，TypeScript 7.0 不再支持 assert 关键字：

// ❌ TypeScript 7.0 报错
import data from "./data.json" assert { type: "json" };

// ✅ 正确写法
import data from "./data.json" with { type: "json" };

这个变化在 6.0 中已有弃用警告，7.0 直接报错。

4.4 Unicode 码点推断修正

模板字面量类型中的 infer 行为发生了重要修正。7.0 之前，TypeScript 将 emoji 等 Unicode 字符按 UTF-16 代理对拆分处理；7.0 之后，按完整的 Unicode 码点处理：

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

// TypeScript 7.0 及之后
type R1 = HeadTail<"😀abc">;
// 结果：["😀", "abc"] ✅ 按完整 emoji 码点处理

// TypeScript 6.x 及之前
type R2 = HeadTail<"😀abc">;
// 结果：["\ud83d", "\ude00abc"] ❌ 按 UTF-16 代理对拆分

迁移建议：如果你的类型体操代码中有意利用 UTF-16 代理对行为进行字符串处理，需要修改类型定义并补充测试用例：

// 需要更新的代码示例
type CharAt<S extends string, N extends number> =
  HeadTail<S> extends [infer Head, infer Tail]
    ? Head extends string
      ? N extends 0
        ? Head
        : CharAt<Tail, [...[] & 0[], 0] extends (infer U)[] ? U : never>
      : never
    : never;

// 修复：确保 emoji 等复杂字符被正确识别为单个字符
type StringToArray<S extends string> = 
  string extends S ? never :
  S extends `${infer Char}${infer Rest}`
    ? [Char, ...StringToArray<Rest>]
    : [];

type Chars = StringToArray<"hello😀world">;
// TS 7+: ["h","e","l","l","o","😀","w","o","r","l","d"]

4.5 JSDoc 分析收紧

7.0 调整了 .js 文件的分析方式，使 JSDoc 类型推导更接近 .ts 文件。以下写法不再被支持：

// ❌ 把值直接放在类型位置
/** @type {someValue} */
const x = 5;

// ✅ 应该改为
const someValue = 5;
/** @type {typeof someValue} */
const x = 5;

// ❌ 单独用 ? 表示类型（Closure 风格）
/** @param {string} */
// ✅ 改为标准 JSDoc
/** @param {string} name - 用户名 */

// ❌ @class 注解函数（Closure 风格）
/** @class */
function MyClass() {}
// ✅ 改用 ES6 class
class MyClass {}

// ❌ Closure 风格的函数类型注解
/** @type {function(string): void} */
// ✅ 改用标准 JSDoc 函数类型
/** @type {(name: string) => void} */

纯 TypeScript 项目通常不受影响，但使用 checkJs: true 或维护 JSDoc 类型定义的库需要处理这些变化。

五、JS API 与工具链兼容性

5.1 7.0 暂不提供稳定 JS API

这是目前最大的生态兼容性挑战。TypeScript 7.0 不提供稳定的程序化 API，意味着以下工具在 7.0 发布时无法直接迁移：

• typescript-eslint：无法使用 TS 编译器 API 进行语义分析
• Volar / vue-tsc：Vue 模板类型检查依赖 TS 编译器 API
• Svelte 语言服务器：Svelte 组件类型检查依赖 TS 编译器 API
• MDX 编译器：MDX 的 JSX + TypeScript 类型检查
• Astro：岛屿架构的类型检查
• Angular 语言服务：模板类型检查

官方预计在 TypeScript 7.1 提供新的 API。微软在公告中明确表示，新的 API 设计将「为更广泛的生态系统」服务，这意味着新的 API 可能与旧的 API 有显著不同。

5.2 @typescript/typescript6 兼容包：双版本并行策略

为了解决工具链过渡期的兼容性问题，微软发布了 @typescript/typescript6 兼容包。这个包提供了以下能力：

安装方式：

# 安装 TypeScript 7（提供新的 tsc 二进制文件）
npm install -D typescript@latest

# 安装 TypeScript 6 兼容包（提供 tsc6 和 TS 6 API）
npm install -D @typescript/typescript6

package.json 配置（用于工具链并行）：

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

这样配置后：

• tsc 命令使用 TypeScript 6（兼容包）的 tsc6，提供旧的 API
• npx tsc 同样使用 TypeScript 6
• @typescript/native（TypeScript 7）提供新的 tsc7 命令行工具

使用 TypeScript 7 的命令行工具：

# 直接使用 TypeScript 7 的 tsc
npx tsc7 --version
npx tsc7 --noEmit

# 或者使用 node_modules/.bin 下的原生 tsc
./node_modules/.bin/tsc7

5.3 生态迁移时间表预估

基于微软公告中「每 3-4 个月一个新版本」的发布节奏，以下是合理的迁移时间表预估：

• 2026 年 7 月（7.0 GA）：主流工具链开始适配，typescript-eslint 7.x alpha 发布
• 2026 年 10-11 月（7.1）：新 JS API 稳定，主流工具链（typescript-eslint、Volar）发布支持版本
• 2026 年底-2027 年初：大多数项目可以安全升级到单版本策略

六、升级路径：步步为营的实战指南

6.1 升级前的准备工作

第一步：更新到 TypeScript 6 并清除所有弃用警告

这是最容易被跳过的步骤，但它决定了你的项目能否平滑升级到 7.0。

# 1. 更新到 TypeScript 6 最新版本
npm install -D typescript@^6.0.0

# 2. 开启 stableTypeOrdering 以发现潜在问题
# 在 tsconfig.json 中添加
npx tsc --showConfig | jq '.compilerOptions.stableTypeOrdering'
# 如果返回 undefined，在 tsconfig 中显式设置 stableTypeOrdering: true

# 3. 删除所有 ignoreDeprecations 配置
# 在 tsconfig.json 中删除以下配置（如果有）
# "ignoreDeprecations": "..."

# 4. 修复所有 TS 6 报告的弃用警告
# 运行全量类型检查
npm run typecheck  # 或 npx tsc --noEmit

# 5. 确认所有警告都已清零

第二步：更新配置文件

// tsconfig.json 检查清单
{
  "compilerOptions": {
    // ✅ 如果使用 es5 target → 升级到 ES2015+
    "target": "ES2019",

    // ✅ 如果使用 module: "commonjs" 等 → 改为 ESNext
    "module": "ESNext",

    // ✅ 如果使用 moduleResolution: "node" → 改为 "bundler"
    "moduleResolution": "bundler",

    // ✅ 显式设置 rootDir
    "rootDir": "./src",

    // ✅ 如果需要 @types，显式声明
    "types": ["node", "jest"],

    // ✅ 检查是否设置了 esModuleInterop: false（需要改为 true 或删除）
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,

    // ✅ baseUrl 如已设置，确保 paths 格式正确
    "paths": {
      "@/*": ["./src/*"]
    },

    // ✅ 删除所有弃用的配置项
    "downlevelIteration": false, // ❌ 删除此行
    "baseUrl": "."               // ❌ 删除此行
  }
}

6.2 升级到 TypeScript 7

安全升级步骤：

# 1. 安装 TypeScript 7
npm install -D typescript@^7.0.0

# 2. 验证最终配置（这个命令会显示 tsconfig.json 被解析后的完整配置）
npx tsc --showConfig

# 3. 运行全量类型检查
npm run typecheck

# 4. 如果有 Jest 测试，确保 jest.config.js 中的 transform 配置兼容
// 如果使用 ts-jest，确保版本 >= 29.x
npm install -D ts-jest@latest

# 5. 如果使用 ESLint，确保 eslint-plugin 的 TypeScript 版本兼容
npm install -D @typescript-eslint/parser@latest @typescript-eslint/eslint-plugin@latest

# 6. 运行测试套件
npm test

并行参数配置建议：

# 在 monorepo 根目录
tsc -b packages/*/tsconfig.json --checkers 4 --builders 4

# 在 CI 环境，先测试不同 worker 数量的性能
# job1: tsc --checkers 2 --builders 2
# job2: tsc --checkers 4 --builders 4
# job3: tsc --checkers 8 --builders 8
# 选择峰值内存 < 内存限制且总时间最短的配置

6.3 暂缓升级的场景

立即升级（安全区）：

• 纯 tsc 项目，不依赖编译器 API
• 基础类型体操，不涉及复杂的 UTF-16 代理对操作
• 使用现代配置（ESNext module、无 es5 target、无 node moduleResolution）

暂缓升级（等工具链适配）：

• 依赖 typescript-eslint（等 7.x 版本发布）
• 依赖 Volar / vue-tsc（等 Vue Language Tools 7.x）
• 依赖 Angular 语言服务
• 维护大型 JSDoc 类型定义库（等生态确认兼容性）
• 依赖编译器的程序化 API（等 TypeScript 7.1）

七、工程意义：对前端工具链格局的深远影响

7.1 编译器性能与 DX 体验的哲学

TypeScript 7.0 的发布，引发了一个关于「开发者体验」的深层思考：编译器性能是否应该被视为语言的 core competency？

答案是肯定的。一个每分钟触发数十次类型检查的 IDE，一个每次 CI 跑 10 分钟类型检查的大型 monorepo，编译器的性能直接影响工程师的生产力和心情。微软此次用 Go 重写编译器，本质上是将 TypeScript 从「够用」提升到「优秀」的工程化决策。

7.2 对前端工具链格局的连锁反应

Bun 的前车之鉴：2026 年 5 月，Bun 从 Zig 迁移到 Rust（由 Claude Code 主导）。而现在，TypeScript 从 TypeScript/JavaScript 迁移到 Go。两条路径的共同点是：用更系统级的语言重写核心工具，以获得数量级的性能提升。

Vite+ 的整合趋势：TypeScript 编译器性能提升后，Vite、Rspack 等构建工具的类型检查流程将更加流畅。结合 Oxc（Rust 编写的 JS 工具链），前端工具链的「Rust/Go 化」趋势正在加速。

JavaScript 运行时的新格局：Bun（Rust）、Deno（Rust）、Node.js（C++）在运行时层面展开性能竞争，而 TypeScript 编译器则在语言服务层面完成了切换。这给 JavaScript/TypeScript 生态带来了一个深刻的隐喻：语言的核心基础设施正在被 Rust 和 Go 接管，而上层应用开发仍然由 JavaScript/TypeScript 主导——这是一种分工，也是一种进化。

7.3 对 AI 编程时代的暗示

2026 年，我们已经看到了多个「AI 辅助语言重写」的案例：Bun（Zig→Rust）、TypeScript 7.0（TypeScript→Go）。这些案例有一个共同模式：AI 越来越擅长处理大规模代码翻译，而这种翻译的价值在于将高层语言的生产力与底层语言的高性能结合起来。

可以预见，未来会有更多的工具链项目选择「用 AI 做语言迁移，用新语言重写性能关键路径」。这不是一种趋势的终结，而是工程实践的一次范式转换——语言的选择正在从「团队最熟悉」进化到「任务最合适」。

八、总结与展望

TypeScript 7.0 是一次以工程化为核心的版本更新。微软用一年多的时间，用 Go 语言重写了整个 TypeScript 编译器，带来了 8-12 倍的性能提升、并行类型检查能力和全新的语言服务架构。这是 TypeScript 发展历程中的重要里程碑，也是前端工具链向系统级语言迁移的又一个里程碑。

对于开发者来说，现在的选择是清晰的：

• 如果你在使用纯 tsc 项目，立即升级到 7.0，享受编译速度的质变
• 如果你依赖 typescript-eslint 等工具链，等 7.1 发布的新 API 和工具链兼容版本
• 无论哪种情况，先把项目配置现代化（ESNext module、无 es5 target、现代 moduleResolution），这才是最重要的长期投资

TypeScript 7.0 证明了一件事：编译器不是语言的附属品，而是开发者体验的核心。当编译器变快，所有的工具、IDE、CI 都会随之受益。这是一次值得被记住的工程实践，也是一个关于「工具进化」的绝佳案例。

参考资料

• Microsoft TypeScript 7.0 Announcement (2026-07-08)
• TypeScript 7.0 RC Release Notes
• icodex TypeScript 7.0 升级指南 (2026-07-12)
• 腾讯网：基于 Go 语言重写，微软正式发布 TypeScript 7.0 (2026-07-17)