TS编译性能优化与增量编译

可视化演示

展示TS全量编译流程、增量编译的文件变更检测与缓存复用机制、以及全量与增量编译的性能对比，交互切换三种模式理解编译优化原理。

编译性能瓶颈

宴会为什么慢？不是大厨手慢，而是“每道菜都重做”这件事本身。假设宴席上有 100 道菜，每道菜平均要 5 分钟，一次全量备菜就是 500 分钟。TypeScript 编译器也一样：一个 10 万行代码的工程，全量编译动辄几十秒甚至数分钟。如果你改一个字就要等这么久，开发节奏会被彻底拖垮——这就像客人催菜时，你还在从头熬高汤。

编译器的工作分三步：解析（把 .ts 源码拆成语法树）、类型检查（沿着 import 引用关系逐文件核对类型）、产物生成（输出 .js 与声明文件）。全量编译时，这三步对每一个文件都要完整执行，而且类型检查是跨文件的：一个文件里定义了接口，一百个文件引用了它，改动这个接口，那一百个文件都要重新核对一遍。因此耗时随文件数量线性增长，而类型检查的波及面还会让实际耗时远超想象。

所以问题一目了然：全量编译相当于“每次加菜都重做整桌”。要提速，就得像聪明的厨师那样——不做无用功。接下来我们看看那本“工作笔记”是怎么改变一切的。

增量编译原理

大厨的工作笔记，就是 TypeScript 的 .tsbuildinfo 文件。它记录了三样东西：每个文件的“版本指纹”（内容哈希）、文件之间的依赖关系、以及哪些文件已经完成。有了它，编译器就像有了“记性”——不再是一个每次开工都失忆的临时工。

开启 incremental 编译选项后，tsc 每次编译会先读取 .tsbuildinfo。编译时，它先对比所有文件的哈希，找出真正变更的文件；再沿着依赖图，找出“下游受影响”的文件——比如你在 a.ts 里改了一个接口，import 了 a.ts 的 b.ts、c.ts 都要重新做类型检查。只有这部分文件会被重新处理，其余文件直接从缓存标记为已是最新，连打开都不需要。

记事本的威力在于“知道什么不用做”。不过，当宴会规模大到几十个团队同时备菜时，一本笔记本也不够——我们需要把厨房分成若干个独立灶台，这就是项目引用。

项目引用拆分

一家大餐厅有三层楼：一楼冷菜、二楼热菜、三楼甜点。如果所有菜都挤在一个灶台做，光找锅铲就要半天。Project References 的思路就是把工程拆成多个子项目，每个子项目有自己的菜谱（tsconfig）和成品（编译产物），就像分灶管理，各灶互不干扰。

根 tsconfig.json 通过 references 字段列出子项目；每个子项目必须开启 composite: true（它自动开启 incremental 并强制生成 .d.ts 声明文件）。构建时，被依赖的项目先构建，产出声明文件；依赖方只需读取这些声明文件，而不用重新解析源码。构建顺序由依赖图决定——这就是拓扑排序：先做冷菜，再做热菜，最后拼盘，次序不能乱。

分灶之后，热菜师傅再也不用等冷菜师傅的全部步骤，只需要验收对方的半成品。但还有个问题：灶台要烧起来，得有人盯着食材柜——这就是 watch 模式。

Watch模式

宴席筹备期间，采购员会不停把新食材送进后厨。如果每次来一根葱都要把整本笔记翻一遍重算，效率依然很低。聪明的后厨会安排一个“哨兵”守在食材柜前：有新食材进来，他喊一嗓子“xx 换了”，相关灶台才动手。这就是 watch 模式。

tsc --watch 会启动两个机制：文件系统监听（fs.watch）捕捉文件变动事件，以及基于 .tsbuildinfo 的增量重建。为了防止你连续按 Ctrl+S 十次就触发十次编译，事件会先进入队列，经过一个短暂的防抖窗口才触发编译——你连续保存三次，它只编译一次。编译完成后，它还会通过内部 API 通知编辑器刷新类型信息，让 IDE 的错误提示几乎实时更新。

哨兵让大厨不用“一分钟重看一遍 20 道菜谱”。不过，不是每家餐厅都用同一套锅具——不同构建工具，就像是不同流派的厨房。接下来我们串门看看。

构建工具集成

同样是做菜：传统大锅菜（webpack + ts-loader）讲究原汁原味但慢；快炒店（esbuild/swc）用猛火大铁锅，几分钟出锅却不上妆；中央厨房（babel）负责把半成品切好装盒，不做质量检验；一体化餐厅（vite）直接让快炒师傅掌勺，再单独安排质检员。

webpack 生态里，ts-loader 逐文件用 tsc 转译，类型检查默认串行，很慢；社区常用 fork-ts-checker-webpack-plugin 把类型检查挪到独立进程并行。babel 用 @babel/preset-typescript 只做“剥类型”的转译，速度快但完全不做类型检查。swc 和 esbuild 用 Rust/Go 并行转译，速度比 tsc 快一两个数量级，同样牺牲类型检查。vite 在开发期用 esbuild 预构建依赖，再配合 tsc --noEmit 单独做类型检查。

选哪家厨房取决于你要不要质量检验。但无论哪一派，都有几招通用的“省时秘笈”——下一节我们翻开大厨的锦囊。

优化策略

大厨的锦囊里装着几条老规矩：隔夜高汤不用再尝咸淡（跳过已封装的第三方库检查）；同一种切配交给一人专做（隔离转译）；三四个帮厨同时开工（并行构建）；做好的成品直接入冰箱（缓存复用）。

具体到配置：skipLibCheck: true 让编译器跳过所有 .d.ts 声明文件的类型检查——第三方库通常在发布前已自检，重复检查纯属浪费。isolatedModules 配合 esbuild/swc/ts-loader 的 transpileOnly 模式时，每个文件独立转译、互不等待，天然适合并行。构建器内置的多进程并行（如 webpack 的 parallel 配置）能充分利用多核 CPU。最后，把 .tsbuildinfo 和 node_modules 一起缓存进 CI，'热启动'能省掉大半时间。

锦囊虽小，样样都管用。但真正到了实战，光有锦囊还不够，还要会“望闻问切”——最后我们来一次后厨全面体检。

实践与排查

新来的帮厨说“我们这儿编译好慢”，你不能直接信，要拿秒表逐环节测：从备菜到装盘到底卡在哪一步？这就好比用体检报告说话，而不是凭感觉猜病。

tsc --diagnostics 和 --extendedDiagnostics 会输出各阶段的耗时统计：读文件多少毫秒、类型检查多少毫秒、生成代码多少毫秒，甚至内存占用。排查清单依次看：.tsbuildinfo 是否存在且被 CI 缓存（没有则是冷启动）；是否误开全量编译（比如构建脚本里 tsc 没带 incremental）；依赖图是否过大（大量文件 import 同一个大模块，导致单点被波及面巨大）；是否重复编译 node_modules 里的类型。实践上，把 .tsbuildinfo 提交进版本库或 CI 缓存目录，是收益最大的一步。

体检完，你终于明白：慢不是大厨手笨，而是没带记事本、没分灶、没让哨兵盯梢。把这四件事做齐，百人宴会也能从容不迫。

AI 应用场景

Python 演示

"""Simulate incremental compilation: only rebuild changed files and dependents."""import hashlib  class IncrementalCompiler:    def __init__(self, source_map):        self.source_map = dict(source_map)        self.dep_map = {}           # 被依赖文件 -> 依赖它的文件列表        self.cache = {}             # 文件路径 -> 内容哈希（大厨的记事本）        self.compile_count = 0      # 实际重写文件的次数     def register_deps(self, file, deps):        # 记录 file 依赖了 deps 中的哪些文件        for dep in deps:            self.dep_map.setdefault(dep, []).append(file)     def digest(self, path):        # 计算文件当前内容的指纹（哈希）        return hashlib.md5(self.source_map[path].encode()).hexdigest()     def is_stale(self, path):        # 内容哈希与笔记不一致 => 文件变了        return self.cache.get(path) != self.digest(path)     def rebuild(self, path):        # 重新“编译”并更新笔记        self.cache[path] = self.digest(path)        self.compile_count += 1     def plan(self):        # 找出变更文件，并沿依赖图收集下游        queue, seen = [], set()        for path in self.source_map:            if self.is_stale(path) and path not in seen:                seen.add(path)                queue.append(path)        for path in list(queue):            for downstream in self.dep_map.get(path, []):                if downstream not in seen:                    seen.add(downstream)                    queue.append(downstream)        return queue     def run(self, full=False):        # full=True 模拟全量编译；否则只处理变更及下游        jobs = list(self.source_map) if full else self.plan()        rebuilt = 0        for path in jobs:            if self.is_stale(path):                self.rebuild(path)                rebuilt += 1        return rebuilt, len(jobs)  if __name__ == "__main__":    src = {}    for i in range(8):        src["a%d.ts" % i] = "export const v%d = %d;" % (i, i)    src["app.ts"] = "import {v0} from './a0'"    c = IncrementalCompiler(src)    # app.ts / a1 / a4 / a7 都依赖 a0.ts    c.register_deps("app.ts", ["a0.ts"])    c.register_deps("a1.ts", ["a0.ts"])    c.register_deps("a4.ts", ["a0.ts"])    c.register_deps("a7.ts", ["a0.ts"])    print("cold start : rebuilt %d, checked %d" % c.run(full=True))    c.source_map["a0.ts"] = "export const v0 = 100;"   # 模拟修改 a0    rebuilt, checked = c.run(full=False)    print("incremental: rebuilt %d, checked %d" % (rebuilt, checked))    print("total real rebuilds:", c.compile_count)

1. self.dep_map = {}记录“谁依赖谁”的关系表，相当于菜谱间的关系网。
2. return hashlib.md5(self.source_map[path].encode()).hexdigest()用哈希做“食材指纹”，内容一变指纹就变。
3. if self.is_stale(path) and path not in seen:发现变更文件，并把它们排入待处理队列。
4. for downstream in self.dep_map.get(path, []):遍历下游依赖，把受波及的文件也纳入检查范围。
5. jobs = list(self.source_map) if full else self.plan()全量与增量的分水岭：全量处理所有文件，增量只处理计划队列。
6. c.register_deps("a1.ts", ["a0.ts"])注册依赖关系，告诉编译器 a1 依赖 a0。
7. c.source_map["a0.ts"] = "export const v0 = 100;"模拟真实开发中的一次修改。
8. print("incremental: rebuilt %d, checked %d" % (rebuilt, checked))输出证明：检查面变小，真实重建更少。

常见误区

面试题