核心是构建完成后立即回收未被引用的中间层和构建缓存，通过标准化命令+触发机制实现“构建后自动回收”，而非边构建边清理；Docker构建缓存需显式调用docker builder prune等命令释放，CI/CD中推荐在build后立即执行-prune -f，定时清理可结合cron与日志，BuildKit支持后台GC，生产环境建议组合脚本清理。

核心是构建完成后立即回收未被引用的中间层和构建缓存，不是边构建边清理，而是靠标准化命令 + 触发机制实现“构建后自动回收”。Docker 构建缓存本身不自动释放，必须显式调用 docker builder prune 或组合 docker system prune 才能真正清掉越积越多的过期数据。

构建后立即清理（CI/CD 场景首选）

在流水线最后一步执行清理，避免缓存滞留。关键点在于：清理动作紧随 docker build 之后，且不依赖人工干预。

• 只清未被任何镜像引用的构建缓存（安全推荐）：docker builder prune -f
• 清所有构建缓存（含长期未用但可能被复用的）：docker builder prune --all -f
• 先预估空间回收量（上线前必做）：docker builder prune --dry-run
• GitLab CI 示例：
  - docker build -t myapp:${CI_COMMIT_TAG} .
- docker builder prune -f

定时深度清理（宿主机长期运行环境）

适用于自建构建节点、测试服务器等长期运行场景。每天固定时间执行一次，兼顾效果与稳定性。

Docker Desktop 4.96.1

下载

• 推荐 cron 表达式（每日凌晨 3:15）：15 3 * * * /usr/bin/docker builder prune --all -f >> /var/log/docker-builder-prune.log 2>&1
• 日志记录便于追踪释放量，也方便排查误删
• 该操作不影响正在运行的容器，也不删除已有镜像
• 可搭配 docker system df 监控构建缓存回收率，>90% 就该触发清理

启用 BuildKit 自动 GC（进阶稳定方案）

若已启用 BuildKit（Docker 20.10+ 默认开启），可通过 daemon 配置实现后台自动回收，减轻运维负担。

• 编辑 /etc/docker/daemon.json，加入以下配置：

{
  "features": { "buildkit": true },
  "builder": {
    "gc": {
      "enabled": true,
      "keepStorage": "20GB"
    }
  }
}

• 重启 Docker：sudo systemctl restart docker
• GC 启用后，会定期扫描并自动删除超出 keepStorage 限制的旧缓存，保留最近活跃部分
• 注意：该策略仅作用于 BuildKit 缓存路径（/var/lib/docker/buildkit/cache），不替代手动 prune

组合清理脚本（生产环境兜底保障）

单一命令覆盖不全，建议用脚本统一管理多类资源，尤其适合磁盘敏感型环境。

• 典型清理顺序：停止容器 → 悬空镜像 → 网络 → 构建缓存 → 卷（按需）
• 示例关键命令组合：
  docker container prune -f
docker image prune -f --filter "until=72h"
docker network prune -f
docker builder prune -f
• 加 --filter "until=XXh" 可保留近期缓存，避免频繁重拉基础镜像
• 务必配合日志记录和 docker system df 对比前后空间变化