缓存需按团队节奏精细化控制：低频操作（如依赖安装）前置，高频操作（如源码复制）后置；禁用粗粒度copy；启用buildkit及远程缓存；按shared/locked/private分级隔离；定期清理并监控命中率。

构建缓存不是“开了就快”，而是需要按团队协作节奏做精细化控制——核心是让缓存真正可预测、可共享、可复用。

按变更频率分层组织构建指令

把低频变动的操作（如依赖安装）放在 Dockerfile 前部，高频变动的（如源码）放后面。这样即使每天改代码，依赖层仍能稳定命中缓存。

• COPY go.mod go.sum . && go mod download → 仅当依赖文件内容变化才重建
• COPY . . && go build → 源码变才触发，不影响前一层
• 避免 COPY . /app 这类粗粒度操作，它会让一次 README 修改就失效整个缓存链

统一启用 BuildKit 并配置远程缓存

本地缓存对单人有用，但团队协作必须靠远程缓存。BuildKit 的 content-addressed 缓存机制能跨机器识别“相同输入=相同输出”，不依赖构建顺序或节点环境。

• 启用方式：export DOCKER_BUILDKIT=1
• CI 中推送缓存：docker buildx build --cache-to type=registry,ref=myreg/cache:app --cache-from type=registry,ref=myreg/cache:app -t myapp:latest .
• 确保所有成员和 CI 使用同一 registry 地址和缓存 tag，否则缓存无法复用

定义清晰的缓存共享策略

不同场景需不同隔离等级。Dagger 和 BuildKit 都支持明确的缓存作用域控制，避免“谁构建谁污染”。

• SHARED：适用于主干分支构建，所有 PR 共享同一缓存池，提升整体命中率
• LOCKED：用于并发流水线（如多分支并行构建），写入串行但读取并发，防冲突
• PRIVATE：仅限安全敏感任务（如含密钥的构建阶段），不与其他流程交叉

定期清理 + 自动化验证缓存健康度

缓存不是越多越好。堆积的无效中间层会拖慢扫描速度，甚至掩盖真实缓存失效问题。

• CI 流水线末尾执行：docker builder prune --all --filter until=24h，只保留一天内活跃缓存
• 每日定时检查缓存命中率：解析 docker build 日志中 “Using cache” 出现比例，低于 70% 就要排查 Dockerfile 或上下文问题
• 在 PR 检查中加入缓存提示：自动比对本次构建与上一次的缓存层差异，标出哪些层被强制重建及原因