核心是构建完成后立即回收未被引用的中间层和构建缓存，通过标准化命令+触发机制实现“构建后自动回收”，而非边构建边清理；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
定时深度清理（宿主机长期运行环境）
适用于自建构建节点、测试服务器等长期运行场景。每天固定时间执行一次，兼顾效果与稳定性。
- 推荐 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 -fdocker image prune -f --filter "until=72h"docker network prune -fdocker builder prune -f - 加
--filter "until=XXh"可保留近期缓存，避免频繁重拉基础镜像 - 务必配合日志记录和
docker system df对比前后空间变化
