为什么构建缓存如此重要
在CI/CD流水线中，每次提交都会触发一次完整的构建流程，包括依赖安装、编译、测试等步骤。如果每次构建都从头开始，不仅浪费时间，还会消耗大量计算资源。构建缓存正是为了解决这个问题而存在的------它允许流水线复用之前构建产生的中间产物，从而显著缩短构建时间。
以Java的Maven项目为例，每次构建都需要下载并解析依赖，这个过程可能占据整个构建时间的30%以上。通过缓存本地Maven仓库（~/.m2），可以跳过依赖下载步骤，将构建时间缩短到原来的1/3甚至更少。
构建缓存的底层原理
构建缓存的核心思想是键值存储 。流水线工具（如Jenkins、GitLab CI、GitHub Actions）会为每次构建生成一个缓存键，该键通常由构建上下文决定，例如：
- 项目文件的哈希值（如pom.xml、package-lock.json）
- 构建工具版本
- 分支名称
当流水线执行到缓存恢复步骤时，它会根据这个键去缓存存储中查找对应的归档文件。如果命中，则下载并解压到指定目录；如果未命中，则执行完整构建，并在构建结束后将相关目录打包并上传，同时更新缓存索引。
关键点在于缓存键的粒度 。如果键过于粗粒度（如仅基于分支名），那么不同提交间的构建会互相污染缓存，导致不一致；如果过于细粒度（如基于全部文件哈希），则每次提交都会产生新缓存，命中率极低。因此，实践中通常选择依赖清单文件（如pom.xml、package.json）的哈希作为键，因为这些文件的变化才真正影响依赖集。
最小可运行示例：GitHub Actions中的Maven缓存
下面我们以GitHub Actions为例，演示如何为一个Java Maven项目配置构建缓存。这个示例可以直接用于任何使用Maven的项目。
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up JDK 17
uses: actions/setup-java@v4
with:
java-version: '17'
distribution: 'temurin'
- name: Cache Maven dependencies
uses: actions/cache@v4
with:
path: ~/.m2/repository
key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
restore-keys: |
${{ runner.os }}-maven-
- name: Build with Maven
run: mvn clean verify这个配置的工作原理如下：
- 缓存步骤 ：使用官方
actions/cache动作，指定缓存路径为Maven本地仓库（~/.m2/repository），并生成键ubuntu-latest-maven-<pom哈希>。 - 键生成 ：
hashFiles('**/pom.xml')会计算所有pom.xml的SHA-256哈希，只要依赖声明不变，哈希就不变，从而复用缓存。 - 恢复策略 ：
restore-keys允许在精确键未命中时，回退到最近一次的ubuntu-latest-maven-前缀缓存，提高缓存命中率（例如当新增了一个模块但未改依赖时）。 - 构建步骤：Maven构建时会自动从本地仓库读取依赖，无需重新下载。
这个示例已经足够生产使用。如果你使用其他语言或构建工具，原理完全一样：只需调整path和hashFiles的目标文件即可。
常见误区与优化建议
- 缓存所有文件：只缓存可复现的中间产物，如依赖目录、编译输出，不要缓存临时文件或日志。
- 忽略缓存清理 ：CI平台通常有缓存大小限制，建议在项目中使用
mvn dependency:go-offline等命令提前下载依赖，或定期清理旧缓存。 - 不区分分支 ：对于长期分支，可以为
main分支设置独立的缓存键，避免与功能分支相互覆盖。
最后，建议在你的CI脚本中增加cache步骤的日志输出，方便排查缓存是否生效。构建缓存是一个性价比极高的优化手段，值得每个项目引入。