缓存策略是什么
CI 缓存通过 pull / push / pull-push 控制读写角色：受信任的作业负责写缓存，其余作业只读，降低污染面。缓存是用一致性换速度：跳过重复下载与编译，但缓存内容错了，构建结果就会错——所以键设计、失效策略与写入权限都是治理点。GitLab 的 cache:policy 与 GitHub 缓存的分支隔离规则是两种典型实现。
基本信息
| GitLab | cache:policy 可选 pull、push、pull-push（默认） |
|---|---|
| GitHub | 缓存按分支隔离，但默认分支的缓存可被其他分支（含 PR）恢复 |
| 失效手段 | 改键前缀、调整键输入文件、清理缓存 |
| 键设计 | 键里放锁文件哈希或工具版本，依赖变化时自动偏离旧缓存 |
缓存写入权限分配
| 作业 | policy | 理由 |
|---|---|---|
| 默认分支构建 | push 或 pull-push | 唯一受信任的缓存源 |
| PR 构建 | pull | 不可信代码不能写共享缓存 |
| 发布作业 | pull | 只消费已验证的缓存 |
| 工具链预热 | push | 独立低风险缓存键 |
典型使用场景
- 依赖安装加速：node_modules、Go 模块、Maven 仓库挂缓存，缩短安装阶段
- 编译加速：增量编译产物与镜像层结合，减少重复构建
- 工具链分发：CI 镜像或二进制工具缓存到内网，降低外网依赖
- 污染控制：只让默认分支写缓存，PR 与外部贡献只读
- 失效管理：依赖升级时自动切换缓存键，避免读到旧依赖
- 本地与 CI 共用键命名规范：减少「我这能跑」的环境差异问题
GitLab 只读缓存
GitLab 只读缓存
default:
cache:
key: deps-$CI_COMMIT_REF_SLUG
policy: pull
paths: [.cache/]
# 仅默认分支允许写缓存
build-main:
rules: [{if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'}]
cache:
policy: pull-push缓存由不可信代码写入可能被投毒：限制可写缓存的作业范围（例如仅默认分支）。
键的粒度要匹配复用范围：按分支键隔离好、复用面小；带锁文件哈希命中稳定、依赖一变即失效，按步骤取舍。