TypeScript 如何做增量编译

很多前端小伙伴都有过这样的体验：写了几行代码，等TypeScript（简称TS）编译的时候，要等好几秒——尤其是项目文件多了之后，每次改一点就全量编译，效率低到影响开发节奏。这时候TS的增量编译就派上用场了，它不是什么复杂的黑科技，核心逻辑其实和咱们平时整理书桌很像。

什么是增量编译？一句话讲明白

咱们先抛开技术术语，用生活化的例子理解：假设你是整理书桌的人，全量编译就是每次整理都把整个房间的所有东西全部重摆一遍，哪怕只动了一支笔；而增量编译是只改你动过的那支笔的位置，其他不动。TS的增量编译，就是只编译上次编译后有变化的文件，不用从头到尾重新编译整个项目，自然就快了很多。

那它怎么判断哪个文件变了？其实是靠“编译记录”——TS会在编译时生成一份记录清单，记着每个文件上次编译的时间、内容哈希值（简单说就是内容的“指纹”），下次编译前先对比这个清单，只要指纹或时间变了，才会重新编译这个文件，没变的直接跳过。

怎么开启TS的增量编译？两步就能搞定

开启增量编译一点不复杂，只要改两个配置，新手也能轻松上手：

第一步，在项目的tsconfig.json里加两个核心配置：incremental设为true，告诉TS“我要开增量编译”；再加个outFile？不对，是tsBuildInfoFile，用来存刚才说的编译记录，比如设成"./.tsbuildinfo"，这个文件会自动生成，不用手动写。

举个实际的小例子，改完的配置片段大概是这样：

`json

{

"compilerOptions": {

"incremental": true,

"tsBuildInfoFile": "./.tsbuildinfo"

}

}

`

第二步，以后运行编译命令，就用原来的tsc就行——TS会自动识别这个.tsbuildinfo文件，自动触发增量编译，不用额外改命令。

增量编译的“小脾气”：哪些情况它会“失灵”？

增量编译不是万能的，有几个常见场景它会乖乖全量编译，别踩这些坑：

第一个坑：修改了配置文件tsconfig.json。比如你把target从ES5改成ES6，相当于给TS换了套“规则”，不管改没改代码，都得重新按新规则编译所有文件。

第二个坑：依赖的第三方包变了。比如你改了node_modules里的某个包代码，TS会把这个包关联的所有依赖一起重新编译，因为这些包是项目编译的基础，基础变了就得全量更。

第三个坑：清理了.tsbuildinfo文件。如果你把这个记录删了，TS就忘了上次编译的情况，只能从头全量编译，所以别随便删它（如果编译出问题删了重置也可以，只是会慢一次）。

增量编译能省多少时间？看个真实小例子

拿一个中等规模的前端项目说，全量编译可能要5-8秒，开了增量之后，只改了一个组件文件，编译时间基本能压在1秒以内，差了好几倍。如果是大项目，比如有几百个TS文件的业务项目，这个时间差会更明显——相当于你写代码的间隙就能完成编译，不用等着转圈圈。

现在很多前端工具链也会把TS增量编译集成进去，比如Vite的TS插件、Webpack的TS加载器，只要你开了incremental，工具会自动帮你用，不用额外配置。对咱们开发者来说，它就是个“隐形的效率小助手”，不用特意关注，用了就能省时间。