增量构建不是开关：缓存失效的四类原因

增量构建宣称能把重复编译的时间降下来，但实际项目里经常出现两种极端：有的团队几分钟完成一次验证，有的反而因为缓存判断错误花了更久。差别通常不来自工具选择，而来自是否理解缓存失效的触发条件。

第一类原因是输入定义不稳定。缓存靠比对文件指纹判断能否复用，一旦构建过程把时间戳、机器路径或随机标识写进中间产物，下一次指纹必然变化，所有下游任务全部重跑。这类问题隐蔽，表现为每次都要完全重建却查不出原因。

第二类是任务边界画得太粗。把许多本可独立的处理合并成一个步骤，任何一处改动都会让这个大步全部失效。合理的做法是让任务粒度尽量接近实际依赖范围，宁可多几个小任务，也不要一个什么都做的大任务。

第三类来自外部依赖。从网络拉取的组件如果版本表述不精确，每次解析可能得到不同结果，缓存判断随之失效。解决办法是把外部拉取锁定到明确版本号，并把它单独作为一步，避免污染上层任务的指纹。

第四类容易被忽略：构建目录与源码目录混用、清理脚本无差别删除输出、并行任务写入同一目标文件。这些习惯会同时破坏缓存与可重复性。判断增量构建是否真正生效，有个简单方法：连续执行两次同样的命令，第二次如果耗时没有明显下降，说明复用没起作用，按上面四类逐项排查即可。