docker构建中清理需避开活跃层：docker builder prune安全清理已废弃缓存，自动跳过构建中锁定的中间层；配合docker builder ls确认无活跃任务后执行，避免冲突。
关键不是“等构建完再删”，而是让清理动作避开构建过程本身——Docker 的构建缓存和中间层在构建进行时是被锁定的，强行删除会失败或中断构建。真正安全的做法，是区分“构建中”和“已废弃”状态，只清理明确不再参与任何构建任务的残留层。
识别并跳过正在构建中的镜像层
Docker 在执行 docker build 时，会为每个中间步骤生成临时镜像层，并打上内部引用标记（尤其在 BuildKit 启用时）。这些层不会显示为 <none>:<none></none></none>，而是处于“正在被构建系统持有”状态，docker image prune 和 docker builder prune 默认不会触碰它们。
- 运行中构建的中间层无法被任何 prune 命令删除，Docker 守护进程会自动保护，尝试强制删除会返回
image is being used by build或conflict: unable to remove -
docker images -f "dangling=true"只列出真正悬空的、未被任何构建或运行时引用的层，不包含当前构建中活跃的中间层 - 可通过
docker builder status（BuildKit 启用时）查看是否有活跃构建任务；若有，说明部分中间层正被占用，此时执行 prune 是安全的——它会自动跳过
用 builder prune 替代手动 rmi，避免误伤
docker builder prune 是专为构建场景设计的清理命令，它只清理已完成但未被复用的构建缓存，完全不干扰正在进行的构建：
- 它不会删除正在被
docker build引用的 layer，也不会影响--cache-from的命中逻辑 - 默认只清理 24 小时内无活动的缓存；加
--keep-storage 10GB可保留最近缓存，进一步降低干扰风险 - 配合
--filter type=exec.cached等参数，还能按缓存类型精准筛选，避开构建中依赖的 layer
构建期间禁用自动清理脚本
如果使用定时任务或 CI/CD 流水线自动清理，需确保构建阶段与清理阶段严格隔离：
- CI 中：把
docker builder prune放在build步骤之后、push完成之后，且不在同一 job 的并发步骤中运行 - 本地开发：避免在终端执行
docker build的同时，另一个终端运行docker system prune -f - 可加简单锁机制，例如构建开始前 touch /tmp/docker-building，清理脚本先检查该文件是否存在，存在则跳过
验证清理是否安全的两个小技巧
执行 prune 前快速确认没有风险：
- 运行
docker ps -a --filter status=exited | grep -q 'Up' || echo "无活跃容器"—— 排除容器依赖干扰 - 运行
docker builder ls 2>/dev/null | wc -l，若输出为 0，说明当前无构建任务，此时docker builder prune完全安全
