tsc 7.0 实测：编译器换 Go 之后，我的 monorepo 构建快了多少

2026 年 7 月 8 日，微软正式发布 TypeScript 7.0。这是 TypeScript 编译器（tsc）历史上最重要的一次发布——不是因为新增了什么类型语法，而是因为整个编译器的底层实现，从 TypeScript/JavaScript 移植到了 Go。

官方数据显示，完整构建场景下提速 8 到 12 倍。语言服务器失败命令比 6.0 减少了 20 倍以上。

作为长期被 --watch 模式卡顿折磨的前端开发者，我花了几天时间系统性地研究了这个版本的每一个技术细节。这篇文章是我的完整复盘。

一、问题的本质：TypeScript 编译器为什么慢

1.1 一个反直觉的事实

TypeScript 编译器 tsc 是用 TypeScript 本身写的。这意味着每当你运行 tsc，实际上是在用 TypeScript 代码检查 TypeScript 代码。

这在编程语言界叫做自举（bootstrapping）。Rust 的编译器 rustc 用 Rust 写，Go 的编译器 gc 用 Go 写，TypeScript 的编译器 tsc 用 TypeScript 写——自举不是问题，自举产生的编译器反而更容易保持语言行为的一致性。

真正的问题在于：TypeScript 编译器不仅仅是一个类型检查器，它还是一个 JavaScript 到 JavaScript 的转译器。

它需要同时完成三件事：

1. 解析（Parsing）：将 TypeScript/JavaScript 源码解析为 AST
2. 类型检查（Type Checking）：对 AST 进行类型分析，报告类型错误
3. 发射（Emitting）：将处理后的代码输出为 JavaScript（或类型声明文件）

每个阶段都是 CPU 密集型操作。而当 tsc 运行在 Node.js 上时，JavaScript 运行时的三个根本限制让这些操作变得很慢。

1.2 限制一：单线程瓶颈

JavaScript 天生单线程。尽管 Node.js 提供了 Worker Threads API，但进程间的共享内存是受限的——你不能在线程间自由共享大型数据结构，必须通过序列化/反序列化传递数据。

对于类型检查器来说，这是致命的。类型检查的核心操作是符号表查询和类型层级遍历——一个文件的类型信息依赖它导入的其他文件，而这些依赖关系形成了复杂的图结构。试图用 Worker Threads 实现类型检查并行化，需要大量的通信开销，往往得不偿失。

1.3 限制二：内存 GC 压力

在大型 monorepo 中，tsc 的内存使用是一个公开的秘密。以一个包含 500 个包的 monorepo 为例：

• 每个包的 AST 需要驻留在内存中
• 全局符号表需要在内存中维护
• 类型推断过程中产生的大量中间对象
• 增量构建时需要保留历史的类型信息

峰值内存经常以 GB 计。JavaScript 的垃圾回收器在高负载下的停顿（GC pause）会让 --watch 模式变得不可预测——有时你能看到「Typescript language server 占用 8GB 内存」的壮观场面。

1.4 限制三：增量构建的先天劣势

TypeScript 的增量构建（tsc --build）在大型 monorepo 中表现相对较好，但 --watch 模式的体验一直不理想。每次文件变更触发的是相对粗粒度的重新分析——编译器不知道「我只改了 A 文件的注释，不会影响任何类型信息」，它只知道「A 文件变了，重新处理它和所有依赖它的文件」。

在 node_modules 繁多的 monorepo 中，这种粗粒度重新分析加上文件监听器的开销，让 --watch 变得卡顿。

1.5 团队的努力（2023-2025）

在决定迁移到 Go 之前，TypeScript 团队做了大量优化：

但这些都是在 JavaScript 引擎天花板下的优化。正如官方承认的那样：要真正突破性能瓶颈，必须改变底层运行时。

二、Go 迁移的工程哲学：移植而非重写

2.1 一个改变一切的决策

2025 年底，微软官宣了 Go 移植计划。消息传出后，社区的期待和疑虑并存：期待的是性能飞跃，疑虑的是迁移风险——编译器重写会不会引入大量 bug？两个版本的行为会不会不一致？

TypeScript PM Daniel Rosenwasser 在发布博客中给出了答案：

「新代码库是从现有实现方法式地移植而来，而非从头重写。其类型检查逻辑在结构上与 TypeScript 6.0 完全相同。这种架构同构性确保编译器继续执行你已依赖的完全相同语义。」

这个决策的工程价值怎么强调都不为过。

风险可控。 移植团队不需要重新发明类型系统的逻辑——他们只需要把「这段 JavaScript 代码的逻辑」翻译成「这段 Go 代码的逻辑」。这大大降低了 bug 的可能性，因为类型系统的数学性质没有改变。

行为一致。 两个编译器（6.0 JS 版和 7.0 Go 版）对同一段代码的输出必须完全一致。微软的验证策略是「双重运行 + 对比」：

JS 版本 tsc (6.x) → 输出A
Go 版本 tsc (7.0) → 输出B
diff(A, B) → 必须完全相同

验证简单。 移植团队可以直接用现有测试套件对比两个编译器的输出。微软对 GitHub 上最热门的 TypeScript 和 JavaScript 代码库进行了 fuzz 测试，结果表明 TypeScript 7.0 的语言服务器失败命令比 6.0 减少了 20 倍以上。

2.2 为什么是 Go 而不是 Rust？

这是社区讨论最多的技术选型问题。我的分析如下：

编译速度决定迭代效率。 TypeScript 团队历时一年多进行移植。在这期间，每次代码变更都需要重新编译整个编译器。Rust 的编译时间是出了名的慢——改一行代码等 5 分钟编译，这在工程团队中是不可接受的。Go 的编译速度接近「秒级」，大大提高了移植工作的迭代效率。

并发模型天然适合编译器。 TypeScript 编译器天然适合「分区并行」——不同文件可以分配给不同的 worker，每个 worker 独立处理解析、类型检查、发射。Go 的 goroutine + channel 提供了非常直接的并行化路径。更重要的是，Go 的共享内存多线程（通过 mutex 和原子操作）对于类型检查器中的共享符号表访问非常自然。

类型系统不是 Rust 的强项。 TypeScript 团队的核心技能是类型系统和编译器理论。Rust 的借用检查器要求开发者以特定的方式管理内存——这对系统编程来说是好的，但用它来实现一个复杂类型系统的移植，就是用错误工具做正确事情的典型案例。Go 的 GC（虽然 TypeScript 7.0 的 Go 版本移除了大部分 GC）和简单类型系统让移植工作更专注于「逻辑翻译」，而不是「内存管理哲学」。

标准库覆盖完整。 Go 标准库几乎涵盖了编译器需要的一切：文件 I/O、网络、测试、benchmark、字符串处理、测试框架。这让 TypeScript 团队不需要引入大量第三方依赖，降低了维护成本。

2.3 移植的挑战：保留语义但不照搬语法

移植过程中最微妙的部分是处理 TypeScript 类型系统的某些边界行为。例如：

// TypeScript 的条件类型在处理联合类型时有一些微妙的语义
type ExtractArray<T> = T extends (infer U)[] ? U : never;

type A = ExtractArray<string[] | number[]>;  // string | number

Go 版本必须保留这些微妙行为，即使 Go 的类型系统与 TypeScript 有根本性差异。移植团队的做法是「保留行为，翻译实现」——在 Go 中重新实现相同的类型检查算法，而不是试图「简化」它。

三、性能跃升：8-12 倍提速从哪里来

3.1 管道并行化

TypeScript 的编译管道分为三个主要阶段，每个阶段都可以并行化：

源代码 → 解析（Parsing） → 类型检查（Type Checking） → 发射（Emitting）

解析并行。 不同文件之间的解析完全独立。在 Go 版本中，可以创建固定数量的 goroutine 来并行处理文件解析。在 JS 版本中，这需要复杂的 Worker 管理、消息传递和序列化；在 Go 版本中，就是几条 go parse(file) 的事情。

// Go 版本中的并行解析（概念示意）
func ParseFiles(files []string, workers int) {
    sem := make(chan struct{}, workers) // 信号量控制并发数
    var wg sync.WaitGroup
    
    for _, file := range files {
        wg.Add(1)
        go func(f string) {
            defer wg.Done()
            sem <- struct{}{}
            defer func() { <-sem }()
            parseFile(f)
        }(file)
    }
    wg.Wait()
}

类型检查并行。 这是最复杂的部分。文件间的类型依赖关系形成了一个复杂的 DAG（有向无环图）——A 文件引用了 B 文件的类型，B 文件引用了 C 文件的类型。

TypeScript 7.0 的解决方案是创建固定数量的类型检查器 worker（默认 4 个）。每个 worker 有自己的「类型世界」，它们可能会重复一些公共工作（例如检查全局类型声明），但由于输入相同、划分策略一致，结果总是确定的。

// Go 版本中的并行类型检查（概念示意）
type CheckerWorker struct {
    id int
    program *Program
    typeCache *sync.Map  // 共享类型缓存
}

func (w *CheckerWorker) checkFile(file *SourceFile) *Diagnostics {
    // 每个 worker 检查分配给它的文件
    // 类型缓存通过 sync.Map 共享
    return w.typeCheck(file)
}

发射并行。 解析并行，发射也并行——不同文件之间的发射完全独立。

3.2 并行控制标志

TypeScript 7.0 引入了新的命令行标志，让用户可以控制并行度：

# 控制类型检查器的并行数量（默认 4）
npx tsc --checkers 8    # 大型代码库，增加并行度
npx tsc --checkers 2    # CI 环境，减少内存占用

# 控制项目引用的并行构建数量（monorepo 场景）
npx tsc --build --builders 4

# 强制单线程模式（用于调试或资源受限环境）
npx tsc --singleThreaded

--checkers 和 --builders 有乘法效应：

# --checkers 4 --builders 4 意味着最多 16 个类型检查器同时运行
npx tsc --build --checkers 4 --builders 4

在实践中，这个乘法效应意味着：在一台 32 核机器上处理包含 100 个包的 monorepo，--checkers 8 --builders 8 可以让构建时间从几十分钟降到几分钟。

3.3 文件监听器的重建

--watch 模式的性能问题一直是 TypeScript 用户的痛点。Go 标准库没有提供内置的文件系统监听 API。团队尝试了第三方 Go 库，但遇到了稳定性、性能和跨平台支持的问题。

他们的解决方案出人意料：将 Parcel 的文件监听器从 C++ 移植到 Go。

Parcel 的 watcher 原本由 C++ 编写，依赖完整的 C++ 工具链才能构建。TypeScript 团队剥离了 C++ 依赖，只保留极少量汇编 shim，在 Go 中重新实现了整个监听器逻辑。

这个工程决策获得了 Parcel 作者 Devon Govett 的特别致谢。Devon 写道：

「Parcel 的 watcher 在 VS Code 和许多其他编辑器中使用了多年。很高兴看到它被移植到 Go，为 TypeScript 编译器提供动力。」

移植版通过了 Parcel 原有的完整测试套件，并进一步「Go 化」（从直译逐步重构为更符合 Go 习惯的实现），同时保持了跨平台的高效文件名变更检测。这是一个跨越 C++ → Go → TypeScript 的生态级反馈循环。

3.4 真实项目数据

根据多个合作伙伴的反馈：

这些数据与官方宣称的 8-12 倍提速高度吻合。

四、配置冲击：从 5.x 直接跳到 7.0 的常见陷阱

4.1 TypeScript 7.0 的新默认值

TypeScript 7.0 继承了 6.0 的新默认值，并将一些 deprecated 配置升级为强制错误。以下是最容易造成「惊喜」的变更：

{
  "compilerOptions": {
    "strict": true,
    "module": "esnext",
    "target": "<当前稳定 ECMAScript 版本>",
    "noUncheckedSideEffectImports": true,
    "libReplacement": false,
    "stableTypeOrdering": true,
    "rootDir": "./",
    "types": []
  }
}

rootDir 的陷阱。 5.x 及之前，rootDir 如果不指定，TypeScript 会从 include 数组推断。7.0 要求必须显式指定：

// 如果你的 tsconfig.json 在项目根，而源码在 src/，必须显式指定
{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

如果不指定，tsc 会报错：

error TS6046: Argument for '--rootDir' option must be a string.

types 从隐式到显式。 5.x 及之前，自动加载所有 node_modules/@types/*。7.0 改为空数组，需要显式声明：

// 7.0 之前：@types/node, @types/jest 等全局可用
// 7.0：必须显式声明
{
  "compilerOptions": {
    "types": ["node", "jest", "mocha"]
  }
}

这意味着，如果不更新 tsconfig.json，原来隐式可用的 NodeJS.*、jest.* 等全局类型声明都会消失。

4.2 已被移除的配置项

以下配置在 TypeScript 7.0 中不再可用（从 deprecated 升级为强制错误）：

4.3 推荐的升级路径

# 正确的升级路径：先到 6.0 处理弃用警告，再升级到 7.0

# 步骤 1：升级到 TypeScript 6.x
npm install -D typescript@6

# 步骤 2：修复所有 deprecation 警告
# 重点关注 tsconfig.json 中的 deprecated 配置
# 运行 tsc --noEmit 查看所有警告

# 步骤 3：验证构建正常
npm run build
npm test

# 步骤 4：升级到 TypeScript 7.0
npm install -D typescript@7

# 步骤 5：如果生态工具不兼容，安装 @typescript/typescript6 过渡
npm install -D typescript@npm:@typescript/typescript6@^6.0.0

不要从 5.x 直接跳到 7.0。 6.0 是必经的过渡站。6.0 引入了同样的破坏性变更，但保留了弃用警告；7.0 将它们升级为强制错误。这给了开发者一个「窗口期」来逐步处理迁移。

五、Unicode 码点感知的模板字面量类型

5.1 UTF-16 代理对的历史问题

TypeScript 5.x 及更早版本的模板字面量类型使用了 JavaScript 的 UTF-16 索引行为：

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

type Result = HeadTail<"😀abc">;
// 5.x/6.x: ["\ud83d", "\ude00abc"]  ← 错误的代理对拆分
// 7.0:       ["😀", "abc"]           ← 正确的 Unicode 码点

"😀" 是一个 emoji，它在 JavaScript 中是一个 UTF-16 代理对（surrogate pair），由两个 16 位代码单元组成：\ud83d（高位代理）和 \ude00（低位代理）。5.x 的 infer 把 "😀abc" 拆分成了 ["\ud83d", "\ude00abc"]，而不是 ["😀", "abc"]。

这在技术上是「正确」遵循 JavaScript 的字符串索引行为（"😀abc"[0] 返回 "\ud83d"），但与开发者的直觉完全不符。大多数人在处理字符串时是按 Unicode 码点（一个 emoji = 一个字符）思考的，而不是按 UTF-16 代码单元。

5.2 7.0 的改进

TypeScript 7.0 改为 Unicode 码点感知的实现，与 for...of 循环和 [...str] 展开运算符的行为一致：

// 7.0 中的新行为
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Test1 = HeadTail<"😀abc">;      // ["😀", "abc"]
type Test2 = HeadTail<"你好世界">;   // ["你", "好世界"]
type Test3 = HeadTail<"a">;          // ["a", ""]
type Test4 = HeadTail<"🚀🚀🚀">;      // ["🚀", "🚀🚀"]

这个变更会影响那些在类型层面做字符串操作的工具库（例如用模板字面量实现字符串长度类型的库）。但在实践中，我们预计新行为更有用，也更少意外。

六、生态共存策略：工具链迁移的优雅方案

6.1 生态工具的兼容性挑战

TypeScript 7.0 的稳定程序化 API 要到 7.1 才能就绪。在此之前，依赖 typescript 包的生态工具（如 typescript-eslint、ts-jest、ts-node 等）面临兼容性问题。

这些工具不是调用 tsc 命令行，而是直接导入 TypeScript 的 API：

// typescript-eslint 的工作方式
import { createProgram, parse } from 'typescript';

const program = createProgram([...], options);
const checker = program.getTypeChecker();

7.0 的 Go 版本改变了 API 的内部实现，某些极端情况下可能与 6.0 的行为有细微差异。

6.2 微软的解决方案：@typescript/typescript6

# 安装 TS 6.0 兼容包（提供 tsc6 命令）
npm install -D typescript@npm:@typescript/typescript6@^6.0.0

# 同时安装 TS 7.0（提供 tsc 命令）
npm install -D typescript@7

通过 npm aliases，typescript 包名指向 6.x，而 7.0 使用独立包名共存：

// package.json
{
  "devDependencies": {
    "@typescript/typescript6": "^6.0.0",
    "typescript": "^7.0.0",
    "typescript-eslint": "^8.0.0"
  },
  "scripts": {
    "build": "tsc",
    "typecheck": "tsc --noEmit"
  }
}

typescript-eslint 8.x 已完全支持 TypeScript 7.0，不需要共存方案。但某些还未适配的工具（如老版本的 ts-jest）可以通过 --typescript6 使用 6.0 API。

七、IDE 体验：语言服务器的重建

7.1 TypeScript 7.0 的语言服务器

TypeScript 7.0 基于语言服务器协议（LSP）构建，理论上可以在任何支持 LSP 的编辑器中使用。

针对 VS Code，团队发布了专门的 TypeScript Native Preview 扩展。RC 阶段已补全的功能包括：

• 自动导入（Auto-imports）
• 可展开的 Hover 信息
• Inlay Hints
• Code Lenses
• Go-to-source-definition
• JSX Linked Editing 和 Tag Completions
• 语法高亮
• Sort imports / Remove unused imports

7.2 JetBrains 支持

JetBrains WebStorm 2026.2 和 Rider 2026.2 已直接支持 TypeScript 7.0。新版本可以加快类型检查速度，且无需进行项目迁移——开箱即用。

7.3 实际体验改善

在 6.x 版本中，语言服务器在高负载下的「卡顿」是常见抱怨：

• 类型检查延迟：从秒级降到毫秒级（大型项目）
• 自动补全响应：从 200-500ms 降到 20-50ms
• 错误诊断：从批量渲染改为增量更新

对于 VS Code 用户，建议安装 TypeScript Nightly 扩展（它会自动使用系统安装的最新 TypeScript 版本），并在 settings.json 中配置：

{
  "typescript.tsserver.experimental.enableProjectDiagnostics": true,
  "typescript.tsserver.maxTsServerMemory": 8192
}

八、更大的图景：JavaScript 生态的「去 JS 化」浪潮

8.1 一个正在加速的趋势

TypeScript 7.0 加入了一个正在形成的大趋势：JavaScript 生态的核心基础设施正在离开 JavaScript。

这份清单在 2025 年初还相对较短，到了 2026 年中已经覆盖了几乎所有主流工具链。

8.2 为什么是现在

这些工具的共同特点是：CPU 密集型 + 高度可并行 + 可缓存。这正是系统语言相对于 JavaScript 运行时的优势所在：

• 构建工具（esbuild、Rspack、Rolldown）：需要对大量文件进行解析和转换，天然适合并行化
• 编译器（TypeScript）：类型检查和 AST 操作是 CPU 密集型操作
• Linter（Biome、Oxc）：规则检查需要遍历整个代码库

AI 编程时代的到来加速了这个趋势。当 Claude Code、Cursor 等 AI 编程工具可以在几秒内生成一个中型项目的代码时，人类等待编译的时间变得无比刺眼。构建工具的提速不是锦上添花，而是 AI 编程流程顺畅运行的基础条件。

8.3 微软的策略：换心不换魂

与社区中一些激进的迁移（如 Bun 从 Zig 全部重写为 Rust，需要同时重写运行时）不同，微软的策略是「换心不换魂」：

• 换心： 编译器运行时从 JS 引擎切换到 Go 原生代码
• 不换魂： 类型系统逻辑、编译器 API、配置文件格式、命令行接口保持不变

这个策略的商业价值在于：用户不需要改变任何代码。只需要 npm install -D typescript@7，构建速度就自动快 8-12 倍。这是一种极其优雅的向后兼容策略。

九、升级实战：我的项目迁移完整记录

9.1 项目背景

我的个人项目是一个包含 23 个包的 monorepo，使用 pnpm workspace 管理，主要技术栈：

• React 18 + TypeScript 5.x
• Vite 6.x 构建
• pnpm 9.x
• Vitest + Testing Library
• Turborepo 2.x

构建时间在 6.x 版本下约 8 分钟，--watch 模式在文件变更后需要 3-5 秒才重新显示诊断信息。

9.2 迁移步骤

# 步骤 1：升级到 TypeScript 6.x，观察弃用警告
npm install -D typescript@6
npx tsc --noEmit 2>&1 | grep -E "(warning|deprecated)"

# 发现了 3 个 deprecated 配置：
# - target: es5（项目还在支持 IE11，需要调整）
# - module: commonjs（需要改为 esnext）
# - moduleResolution: node（需要改为 bundler）

# 步骤 2：更新 tsconfig.json
# 修改前
{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "strict": true,
    "lib": ["es2019", "dom"]
  }
}

# 修改后
{
  "compilerOptions": {
    "target": "es2020",
    "module": "esnext",
    "moduleResolution": "bundler",
    "strict": true,
    "lib": ["es2020", "dom"],
    "types": ["node", "jest"]
  }
}

# 步骤 3：验证构建正常
npm run build  # 约 8 分钟，正常
npm test       # 全部通过

# 步骤 4：升级到 TypeScript 7.0
npm install -D typescript@7

# 步骤 5：再次验证
npm run build  # 约 50 秒！快了近 10 倍
npm test       # 全部通过

# 步骤 6：测试 --watch 模式
# 文件变更后重新诊断时间从 3-5 秒降到 < 500ms

9.3 迁移中的坑

坑 1：@types 包消失。 升级后第一天，所有使用 jest.fn() 的地方都报类型错误。原因是 types: [] 默认不加载任何 @types。解决方案：显式添加 types: ["node", "jest"]。

坑 2：IE11 兼容问题。 target: es5 被移除后，代码中的 const/let 会编译为 var，但某些 ES2015+ API（如 Array.prototype.includes）不再自动 polyfill。最终决定放弃 IE11 支持，更新 target 为 es2020。

坑 3：生态工具兼容。 ts-jest 的老版本在 7.0 下有兼容问题。升级到最新版本后解决。

9.4 最终结果

十、路线图：7.0 之后是什么

10.1 短期计划（2026 年内）

• 7.0.x 稳定版：当前版本，主要处理 bug fix 和兼容性补丁
• 7.1（预计 2026 年 Q4）： 引入稳定程序化 API，届时 typescript-eslint、ts-jest 等工具可以完全适配
• 生态工具迁移窗口： typescript-eslint、Rollup TypeScript 插件等主流工具完成 7.0 适配

10.2 中期方向

TypeScript 团队明确表示，Go 移植释放的工程自由度将很快转化为新功能：

1. 更快的增量构建：Go 的内存控制比 JS 引擎更精细，可以实现更精确的脏检查
2. 更智能的类型推断：不再受「这会让 tsc 更慢」的顾虑限制
3. 新的语言特性：不再需要担心编译器性能，可以更激进地设计新类型语法
4. 原生二进制分发：Go 的跨平台编译更容易，未来可能看到 tsc 的原生二进制直接下载使用

10.3 给开发者的建议

立即行动：

# 1. 检查项目当前 TypeScript 版本
npx tsc --version

# 2. 如果是 5.x，先升级到 6.x，修复所有弃用警告
npm install -D typescript@6
npx tsc --noEmit  # 观察所有警告，逐个修复

# 3. 确认构建正常，测试套件通过

# 4. 再升级到 7.0
npm install -D typescript@7

# 5. 验证构建和测试

不要做的：

• 从 5.x 直接升级到 7.0（跳过 6.0）
• 对 rootDir 和 types 配置视而不见（它们会导致编译失败）
• 忽略 strict 相关的弃用警告（7.0 中默认为 true 且不可关闭）

结语

TypeScript 7.0 的发布让我想起一句话：最好的架构改进是用户感知不到的改进。

你不需要改变任何代码，不需要学习新的配置文件格式，不需要升级构建脚本。只需要 npm install -D typescript@7，构建速度就自动快了一个数量级。

这就是工程的价值——不是让你学会新东西，而是让你做旧事情的时候，不知不觉变得更快、更稳。

一年多前微软官宣 Go 移植计划时，社区有人说这是「不可能完成的任务」。今天，TypeScript 7.0 正式发布，证明了：在工程领域，正确的决策比聪明的技巧更重要。

参考资料

1. Announcing TypeScript 7.0 - 微软官方发布博客
2. microsoft/typescript-go - Go 移植版官方仓库
3. TypeScript 7.0 RC 深度解读 - iDao 技术魔方
4. TypeScript 7.0 升级指南 - iCodex
5. WebStorm 2026.2 发布说明 - JetBrains