核心是构建完成后立即回收未被引用的中间层和构建缓存，需用docker builder prune显式清理，而非运行时自动释放；推荐CI/CD中构建后立即执行或定时任务清理，BuildKit还可配置gc自动回收。
在 Docker 构建过程中自动清理无用缓存，核心不是“边构建边清理”，而是构建完成后立即回收未被引用的中间层和构建缓存。Docker 的构建缓存（BuildKit 或传统 builder）本身不支持运行时自动释放，但可通过标准化命令 + 定时/触发机制实现“构建后自动清理”，真正解决缓存越积越多的问题。
明确要清理什么：构建缓存 ≠ 镜像层
构建缓存是 Docker 在 docker build 过程中为加速而保留的中间产物，包括：
- 未被任何成功构建镜像引用的中间构建步骤（如某次失败构建产生的 RUN 层）
- 已过期的基础镜像依赖层（例如旧版
ubuntu:20.04被替换后残留的构建上下文） - 多分支并行构建产生的临时缓存，不再有后续构建复用
它独立于镜像存储，路径通常在 /var/lib/docker/buildkit/cache（启用 BuildKit 时）或 /var/lib/docker/builder/（旧版），不会随 docker image prune 删除，必须用 docker builder prune 显式处理。
实战：构建后立即清理（推荐 CI/CD 集成）
在 Jenkins、GitLab CI 或 GitHub Actions 中，构建完成后的最后一步加入清理命令，避免缓存滞留：
- 仅清理未使用的构建缓存（最安全）：
docker builder prune -f - 清理所有构建缓存（含可能被引用但长期未用的）：
docker builder prune --all -f - 查看能释放多少空间（上线前先试）：
docker builder prune --dry-run
示例 GitLab CI job 片段：
- docker build -t myapp:${CI_COMMIT_TAG} .
- docker builder prune -f # 紧跟构建后执行，零延迟回收
定时自动清理（适合宿主机长期运行环境）
对 Docker 构建节点（如自建 CI agent），建议每天凌晨执行一次深度清理：
- 编辑 crontab：
crontab -e - 添加一行（每日 3:15 执行）：
15 3 * * * /usr/bin/docker builder prune --all -f >> /var/log/docker-builder-prune.log 2>&1
该命令会删除所有未被当前任意镜像引用的构建缓存，日志记录便于追踪释放量。注意：它不影响正在运行的容器，也不删除已有镜像本身。
进阶：配合 BuildKit 启用自动缓存 GC
若使用 BuildKit（推荐），可在 daemon.json 中配置自动垃圾回收策略：
- 编辑
/etc/docker/daemon.json，添加：
"features": { "buildkit": true },
"builder": {
"gc": {
"enabled": true,
"keepStorage": "20GB"
}
}
}
重启 Docker：sudo systemctl restart docker
此后 BuildKit 会在缓存占用超过 20GB 时自动触发清理，无需脚本干预——这是目前最接近“自动”的原生方案。
