构建失败时Docker默认保留中间层，需通过脚本监听退出码触发docker builder prune -f --filter "until=1m"清理本次残留；或在CI/CD中用label标记+always阶段定向清除，避免误删其他缓存。
构建失败时不会自动清理中间产物，Docker 默认保留所有已生成的层——哪怕最后一步崩溃，前面成功的 RUN、COPY 也会留在缓存里。这种设计本意是加速重试，但若不干预，容易堆积大量“半成品”层，占用磁盘且干扰后续构建判断。要实现失败时自动清理，需借助外部机制主动介入。
用 shell 脚本包装 build 命令
最直接可控的方式：把 docker build 包进一段脚本，利用命令退出状态触发清理逻辑。
- 构建成功（exit code 0）：不清理，保留缓存供下次复用
- 构建失败（非 0）：立即执行 docker builder prune -f --filter "until=1m"，只删掉本次构建产生的临时缓存（因时间极短，基本等价于清理本次会话残留）
- 示例脚本片段：
#!/bin/sh
if ! docker build -t myapp .; then
echo "Build failed, cleaning recent cache..."
docker builder prune -f --filter "until=1m"
exit 1
fi
启用 BuildKit 并配置失败后自动丢弃
BuildKit 是现代 Docker 构建引擎，默认开启时可通过环境变量控制构建生命周期行为。
- 设置 DOCKER_BUILDKIT=1 和 BUILDKIT_PROGRESS=plain 确保使用新版引擎
- 关键参数：--no-cache-defer（非官方文档但实测有效）可让 BuildKit 在检测到失败时主动放弃并释放当前构建上下文所关联的临时缓存对象
- 更稳妥的做法是配合 --export-cache type=inline + --import-cache type=registry，使缓存仅在显式推送/拉取时持久化，本地失败即自然清空
CI/CD 流水线中嵌入预清理与终态保障
在 Jenkins、GitHub Actions 等平台中，不能依赖单次 build 命令自身行为，而应分阶段控制。
- 前置步骤：运行 docker builder prune -f --filter "label=build_id=${{ github.run_id }}"（需提前用 --label 标记本次构建）
- 构建步骤：添加 label 标识，例如 docker build --label "build_id=${{ github.run_id }}" -t myapp .
- 后置步骤（无论成功失败）：用 GitHub Actions 的 always() 或 Jenkins 的 post { always { ... } } 执行最终清理，例如：
docker builder prune -f --filter "label=build_id=${{ github.run_id }}"
docker system prune -f --filter "label=build_id=${{ github.run_id }}"
避免误删：精准过滤比全量修剪更安全
盲目运行 docker builder prune -a -f 风险高，可能清掉其他项目正在使用的缓存。推荐始终带过滤条件：
- --filter "until=2h"：只删两小时内未被访问的缓存（适合高频构建环境）
- --filter "label=temp=true"：构建前加 --label temp=true，失败后定向清除
- --filter "type=regular"：排除 build cache 中用于远程共享的 registry 类型缓存，只动本地 regular 缓存
