缓存清理需主动嵌入CI流水线：构建后立即清理最稳妥；资源敏感型集群宜定时清理；高级场景可结合缓存复用智能清理，关键在时机、范围与并发安全。

构建缓存本身不会自动清理，必须主动介入——关键在于把清理动作嵌入流水线生命周期，让它在合适的时间点、以合适的方式执行，既释放空间又不影响正在运行的构建。

构建后立即清理（推荐用于稳定环境）

这是最常用也最稳妥的方式。在 CI 流水线的最后阶段（比如部署完成或镜像推送成功后），追加一条清理命令，确保本次构建产生的中间缓存不长期滞留。

• GitLab CI 示例：
  after_script:
  - docker builder prune --force
• GitHub Actions 示例：
  - name: Cleanup build cache
  run: docker builder prune --force
  if: always()（保证无论成功失败都执行）
• 注意：该方式只清理本次构建“未被其他镜像引用”的缓存层，安全无副作用，适合大多数项目。

按时间策略定期清理（适合资源敏感型集群）

当多个流水线共享同一台 Runner 或构建节点时，单次构建后清理可能不够——旧缓存仍会累积。此时可配置定时任务，统一回收过期缓存。

• 在 Runner 主机上设置 cron：
  0 4 * * * /usr/bin/docker builder prune --filter until=24h --force（每天凌晨4点删掉24小时前的缓存）
• 或通过 GitLab CI 的 scheduled pipeline 触发清理作业，避免依赖宿主机权限。
• 优势是可控性强；风险在于若过滤条件太宽（如用 --all），可能误删正在被并发构建引用的缓存。

结合缓存复用做“智能清理”（高级场景）

不是所有缓存都要删，有些层被高频复用（比如基础镜像层），保留它们反而提升后续构建速度。可通过 --cache-from + prune 组合实现“用则留、不用则清”。

• 构建时指定远程缓存源：
  docker build --cache-from $CI_REGISTRY_IMAGE:latest -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
• 构建完成后只清理本地未被复用的缓存：
  docker builder prune --filter type=unreferenced --force
• 需要 Docker 23.0+ 和 BuildKit 启用状态（DOCKER_BUILDKIT=1），适合中大型团队精细化治理。

不复杂但容易忽略：清理命令本身很短，难点在于判断何时清、清多少、是否影响并发构建。把清理变成流水线的一个标准环节，比事后手动救火可靠得多。