构建系统优化：增量编译与缓存命中率提升
一、全量编译的时间税
每次改动一行，构建却从头编译全仓。
成千上万个文件被重新处理，绝大多数没变。
工程师在等待里把思路忘光。
增量编译就是为免这笔税。
只重编"受变更影响"的部分。
未变的部分直接复用既有产物。
但增量不是默认就快。
命中率低，等于没增量。
本文探讨如何提升增量编译与缓存的命中率。
二、增量的判定机制
增量编译靠"依赖追踪"。
每个产物记录它的输入指纹：源文件哈希、编译参数、依赖产物哈希。
输入变，则产物失效重编；否则复用。
命中率是核心指标。
它 = 复用的产物数 / 应检查的产物数。
低命中往往因"指纹过粗"或"隐式依赖未记录"。
下面是增量判定的流程：
关键在"指纹完整性"。
漏记一个隐式输入（如生成代码脚本），会导致用了过期产物。
这类 bug 最难查，因为"看起来编译过了"。
三、生产级实现
下面用代码描述基于指纹的产物复用。
python
import hashlib
import json
from pathlib import Path
from dataclasses import dataclass, field
@dataclass
class Artifact:
path: str
inputs: list[str] = field(default_factory=list)
fingerprint: str = ""
def fp(*parts: str) -> str:
return hashlib.sha256("|".join(parts).encode()).hexdigest()[:16]
def needs_rebuild(art: Artifact, sources: dict[str, str]) -> bool:
"""比对当前输入指纹与记录，决定是否重编"""
current = fp(*(sources.get(p, "") for p in art.inputs))
return current != art.fingerprint
def build(art: Artifact, sources: dict[str, str]) -> None:
art.fingerprint = fp(*(sources.get(p, "") for p in art.inputs))
Path(art.path).write_text("compiled", encoding="utf-8")
if __name__ == "__main__":
a = Artifact("out/a.o", inputs=["src/a.c"])
srcs = {"src/a.c": "int main(){}"}
if needs_rebuild(a, srcs):
build(a, srcs)
print("fingerprint:", a.fingerprint)真实构建系统（如 Bazel、Make）自动管理指纹与图。
提升命中率的关键是"显式声明所有输入"，包括生成脚本与配置。
四、构建系统优化的代价与边界
增量编译省时，但坑在正确性。
指纹过粗漏编 。把多个输入合成一个粗指纹，一处变全重编。
但更危险的是过细导致漏变，用旧产物。
应保证指纹覆盖全部真实输入，宁粗勿漏。
隐式依赖是头号杀手 。 Generated 代码、环境变量、工具版本。
任一未入指纹，产物可能在错状态下被复用。
构建系统要对"非文件输入"显式建模。
缓存跨机的一致性 。远程缓存被不同环境写，可能错配。
应按平台、编译器版本分命名空间。
否则复用了不匹配的产物，bug 极难定位。
调试难度 。增量跳过编译，报错栈指向旧产物。
应保留"强制全量重建"开关，排查时一键清零。
增量构建的"可观测性"要跟上。命中率掉了多少、哪类文件总在重编，若看不到，优化就是盲人摸象。建议构建系统输出每次的命中/重编明细，纳入看板，异常下跌能立刻发现。另一个被忽视的点是"开发态 vs CI 态不一致"：本地命中率高，CI 上却全量重编，往往是缓存未挂载或路径差异。应在两环境用同一缓存策略，避免本地快、流水线慢的割裂体验。最后，增量逻辑要有"自检"：定期跑一次全量并与增量结果比对，确认产物一致，防止指纹 bug 导致默默用了过期产物。
五、总结
构建优化，本质是用"精准指纹"换"高命中率"。
机制上靠依赖追踪与输入指纹决定复用。
工程上显式建模全部输入，隔离缓存命名空间。
落地路线：先让构建系统记录完整输入指纹；再排查隐式依赖补入；远程缓存按环境分空间；保留全量重建开关。命中率高，工程师才敢小步快跑。