4. 增量构建原理：增量构建 vs 全量构建、文件变更检测机制、构建缓存命中策略

这一章，我们来聊聊构建加速里最核心的一个概念——增量构建。

说白了，就是「只做必要的，不做重复的」。我见过太多团队，每次构建都从头到尾跑一遍，哪怕只改了一个空格。嗯，这其实是在浪费生命。

4.1 增量构建 vs 全量构建

先看一张对比图，你马上就能明白两者的区别。

全量构建，每次都是「从零开始」。不管你有没有改代码，编译器都会把整个项目重新编译一遍。我早期带的一个 Java 项目，全量构建要跑 15 分钟，每天几十次构建，一天下来几个小时就没了。

增量构建则聪明得多。它只处理那些真正发生变化的文件，其他部分直接拿缓存结果。你想想看，改了一行代码，却要等 10 分钟才能看到效果，这合理吗？

对比维度	全量构建	增量构建
构建范围	所有源文件	仅变更文件 + 受影响文件
构建时间	固定（与项目大小成正比）	与变更量成正比（通常极快）
缓存利用	不利用缓存	最大化利用缓存
适用场景	首次构建、清理构建、CI 全量验证	日常开发、快速迭代、本地调试
资源消耗	高（CPU、内存、磁盘 I/O）	低（仅处理变更部分）

我的建议：本地开发时，尽量用增量构建。CI 流水线里，可以保留每周一次的全量构建作为「健康检查」，其他时候用增量构建加速。

4.2 文件变更检测机制

增量构建的第一步，就是搞清楚「哪些文件变了」。这听起来简单，但实际做起来有不少坑。

常见的检测机制有三种：

时间戳对比：比较源文件和上次构建产物的修改时间。如果源文件更新，就重新编译。
文件哈希校验：计算源文件的 MD5 或 SHA-1 哈希值，与缓存中的哈希对比。哈希变了，说明文件内容变了。
文件系统监听：通过 inotify（Linux）或 FSEvents（macOS）实时监听文件变化，主动触发构建。

我个人习惯用哈希校验。为什么？时间戳有个大坑——你想想看，git checkout 切换分支时，文件时间戳会变，但内容可能没变。这时候时间戳检测会误判，导致不必要的重新编译。我曾经因为这个，浪费了整整一个下午排查构建变慢的原因。

避坑指南：我曾经在一个大型 C++ 项目里，发现增量构建偶尔会「漏编译」。查了半天，原来是文件系统监听机制在高并发场景下丢事件了。后来我加了一层哈希校验兜底，问题才解决。记住：监听机制不可靠，一定要有校验兜底。

来看一个简单的哈希检测伪代码：

# 文件变更检测伪代码
def detect_changed_files(source_files, cache_dir):
    changed_files = []
    for file in source_files:
        current_hash = compute_md5(file)
        cached_hash = read_cached_hash(cache_dir, file)
        if current_hash != cached_hash:
            changed_files.append(file)
            # 更新缓存哈希
            write_cached_hash(cache_dir, file, current_hash)
    return changed_files

这里有个细节：依赖链追踪。你改了 A 文件，但 B 文件引用了 A，那 B 也得重新编译。这就是为什么很多构建工具（比如 Bazel、Gradle）会维护一个完整的依赖图。

4.3 构建缓存命中策略

检测到变更后，下一步就是决定「哪些缓存能用，哪些不能用」。这就是缓存命中策略。

我把它分为三个层级：

缓存层级	命中条件	典型实现	命中率
本地缓存	文件哈希匹配 + 依赖链未变	~/.cache/ 目录、Gradle 缓存	高（本地开发）
远程缓存	构建产物哈希匹配	Nexus、Artifactory、S3 缓存	中（CI 环境）
分布式缓存	内容寻址存储（CAS）	Bazel 远程缓存、BuildKit	高（大规模团队）

本地缓存是最快的，但有个问题——缓存污染。你想想看，如果构建脚本本身变了（比如升级了编译器版本），那所有缓存都应该失效。我见过一个团队，升级了 JDK 版本但没清缓存，结果线上跑出了诡异的 bug，排查了两天才发现是缓存了旧版本的字节码。

  缓存失效的黄金法则：任何影响构建产物的输入发生变化时，对应的缓存必须失效。这些输入包括：源文件、依赖库、构建工具版本、环境变量、操作系统内核版本。

来看一个更完整的缓存命中逻辑：

# 缓存命中策略伪代码
def should_use_cache(module, build_context):
    # 1. 检查构建环境是否变化
    if build_context.env_hash != module.cached_env_hash:
        return False  # 环境变了，缓存失效
    
    # 2. 检查依赖是否变化
    for dep in module.dependencies:
        if dep.hash != module.cached_dep_hashes[dep.name]:
            return False  # 依赖变了，缓存失效
    
    # 3. 检查源文件是否变化
    if module.source_hash != module.cached_source_hash:
        return False  # 源文件变了，缓存失效
    
    # 4. 检查构建参数是否变化
    if build_context.build_flags != module.cached_build_flags:
        return False  # 编译参数变了，缓存失效
    
    return True  # 全部通过，命中缓存

这里我特别想强调一点：缓存粒度。你想想看，是把整个项目作为一个缓存单元，还是按模块、按文件来缓存？粒度越细，缓存复用率越高，但管理成本也越大。我个人习惯按编译单元来缓存——在 Java 里就是每个 .class 文件，在 C++ 里就是每个 .o 文件。

实战技巧：如果你用 Docker 构建，记得把依赖安装和代码编译分成不同的层。这样依赖没变时，可以直接复用镜像层缓存。我见过有人把所有步骤写在一个 RUN 指令里，每次构建都重新下载依赖，白白浪费了几分钟。

最后，说一个很多人忽略的点——缓存清理策略。缓存不是越多越好，磁盘空间有限，而且过老的缓存可能包含安全漏洞。我一般设置缓存保留 7 天，或者当缓存占用超过 10GB 时自动清理最久未使用的缓存。

嗯，增量构建的原理其实不复杂，但要做好并不容易。核心就是三件事：准确检测变更、合理命中缓存、及时清理过期缓存。把这三点做好了，你的构建速度至少能提升 5-10 倍。

📚 课程目录

4. 增量构建原理：增量构建 vs 全量构建、文件变更检测机制、构建缓存命中策略

4.1 增量构建 vs 全量构建

4.2 文件变更检测机制

4.3 构建缓存命中策略