构建越来越慢，我从缓存开始动刀

2026-08-14 构建优化,构建速度,构建缓存,开发效率

那天我给 admin 改一行样式，等了太久才看到结果，中间顺手刷了会儿手机。这已经不是效率问题了，是注意力被切碎。构建速度越来越慢怎么优化，我从缓存开始动刀，顺序是缓存、范围、依赖、最后才是换工具。

先说最贵的一课：我最开始想到的是换构建工具，那是最贵的选项，也是最不该先做的。

一、缓存失效，构建速度越来越慢最常见的原因

现象：以前挺快的构建，某天开始慢下来，而且越来越慢。

为什么踩：缓存文件被删过、被清理脚本扫过，或者配置文件改了一次导致缓存整体失效。之后每次构建都从零开始，自然慢。

怎么避：先确认缓存到底有没有生效。看构建日志里有没有复用缓存的记录，没有就是没命中。先修这个再谈别的，它经常就是全部原因。

现象：只改了一个小文件，构建却像在做全量任务。

为什么踩：依赖关系里出现了不该有的引用，一个基础模块被到处引用，动一下就牵连一大片。也可能是构建配置把整个目录都当成了入口。

怎么避：看构建时到底处理了多少模块，和你的代码量对比一下，比例离谱就说明范围失控了。回头查那个被所有人引用的基础模块，把不该放在里面的东西挪出去。

现象：代码没怎么写，构建时间一点点往上爬。

为什么踩：每次装新依赖都只想着当下这个功能，没人在意它带进来多少东西。依赖的体积和插件数量直接决定构建工作量。

怎么避：定期回头看依赖列表，把只用过一次、或者已经被别的东西替代的删掉。这一步没人提醒就会一直拖，最好定个固定时间做。

在你打算换工具之前，先把下面几件事查一遍：

这份清单查完还没改善，再考虑换工具。换工具是最后一步，因为它的风险和成本都最高，而且会掩盖上面这些问题。

换工具看起来是最彻底的解法，实际是最容易掩盖问题的解法。

原因是它会把构建从头重做一遍，过程中那些拖慢速度的东西可能顺手被清掉了，于是你会觉得「换完确实快了」。但你没搞清楚快的原因是什么，等它再慢下来，你还是不知道从哪查。

我更愿意先搞明白慢在哪，再决定要不要换。搞清楚之后经常发现，换工具是多余的，或者换之前还有几件更值得做的事。

还有一个现实问题：换工具期间你的项目是半停状态，一人项目里这段时间没有替代产能。所以这个决定的代价比想象中高。

构建速度越来越慢怎么优化，思路就一句：先修能修的，再考虑要不要换。顺序反了，你会花更多时间得到更少结果。

Q：构建速度越来越慢怎么优化，先做什么？

A：先确认缓存有没有生效。缓存失效是最常见的原因，修复成本也最低，很多情况下修完就恢复正常速度了。

Q：换成更快的构建工具能解决问题吗？

A：能快一些，但如果原因是构建范围失控或者依赖膨胀，换工具只是把问题一起搬过去，还会附赠迁移风险。

Q：怎么判断构建范围失控了？

A：对比构建处理的模块数量和你的实际代码量。只改一个小文件却处理了大量模块，基本可以确定范围有问题。