2026 年 7 月 9 日，TypeScript 7 发布。

核心变化：编译器从 JavaScript 全面重写为 Go。

但你的代码：

  • 不用改
  • 不用迁移
  • 甚至感觉不到变化

为什么一个编译器的底层语言换了，用户完全无感？

为什么用 Go：性能瓶颈在哪

TypeScript 原来的编译器是用 TypeScript 自己写的，运行在 Node.js 上。

问题：

大型项目（几十万行代码）
    ↓
tsc 编译
    ↓
Node.js 执行 TypeScript 编译器
    ↓
JavaScript 的单线程 + GC 开销
    ↓
编译慢、内存高、IDE 卡顿

TypeScript 7 用 Go 重写编译器，解决了这些瓶颈：

  • 原生机器码，编译速度大幅提升
  • goroutine 并发，多文件可以并行类型检查
  • 内存管理更高效，IDE 响应更快

大型项目的编译时间从分钟级降到秒级。

为什么 API 不变：实现与抽象的分离

TypeScript 从设计第一天起，就把"语言规范"和"编译器实现"分开了。

TypeScript 语言规范（抽象层）
├── 类型系统
├── 语法定义
├── 编译器 API
└── 诊断信息

TypeScript 编译器（实现层）
├── Parser
├── Type Checker
├── Transformer
└── Language Service

实现层可以重写，抽象层保持稳定。

这和 React 的设计哲学一模一样：

React 编程模型（抽象层）
├── JSX 语法
├── Hooks API
├── 组件模型
└── 并发特性

React 运行时（实现层）
├── Reconciler（从递归到 Fiber）
├── Scheduler（从同步到并发）
└── Renderer（从 DOM 到 RN）

React 15 → 18，底层从递归变成 Fiber，但 useState 还是 useState。

TypeScript 4 → 7，底层从 JS 变成 Go，但 interface 还是 interface。

核心洞察

实现可以变化，抽象可以保持稳定。

TypeScript 的类型系统、语法、API 是语言规范的一部分，和编译器用什么语言实现无关。

这就是为什么底层重写后，上层体验不变。