构建中断后应先执行docker builder prune清理构建缓存，再用docker image prune清理真正的悬空镜像（dangling=true），若遇“被停止容器引用”错误，需先用docker ps -a --filter ancestor=image_id -q查出并删除对应容器。
构建中断或失败后，Docker 会留下大量 <none>:<none></none></none> 的匿名镜像（也叫悬空镜像、dangling images），它们是中间构建层，没被打上标签，但可能仍被缓存引用或被已停止的容器依赖。直接用 docker rmi 往往失败，因为存在隐式依赖或“正在被使用”的提示。清理的关键不是硬删，而是分层识别 + 按依赖关系安全释放。
先确认哪些是真正的匿名镜像层
运行以下命令列出所有无标签镜像：
docker images -f dangling=true
它只显示真正“悬空”的镜像——即未被任何其他镜像或容器引用的中间层。注意：这不是所有 <none>:<none></none></none> 镜像，有些虽无标签但仍在构建缓存中被后续层引用，dangling=true 能精准过滤出可安全清理的部分。
优先用 builder prune 清理构建缓存
大多数构建失败残留的问题根源在 BuildKit 缓存，而非镜像本身。推荐第一步执行：
-
docker builder prune—— 清掉所有未被当前镜像引用的构建缓存层（最安全，不影响已有镜像） - 若想清得更彻底（比如重装环境）：
docker builder prune -a—— 删除全部构建缓存，下次build会从头开始
这一步能解决 80% 以上的“删不掉”问题，因为很多 <none></none> 镜像实际只是缓存层的快照，缓存一清，它们自然变为 dangling 状态，后续 image prune 就能顺利处理。
再清理悬空镜像（<none>:<none></none></none>）
确认缓存清理后，再执行：
-
docker image prune—— 默认只删 dangling 镜像，无交互提示，安全 - 加
-f可跳过确认：docker image prune -f - 如果想连带清理那些有标签但没被任何容器使用的镜像（谨慎）：
docker image prune -a -f
⚠️ 注意：docker image prune -a 会删掉所有未被容器引用的镜像（包括你手动打过 tag 但没运行的），不是只删 <none></none>，请按需选择。
遇到 “image is being used by stopped container” 怎么办
如果某匿名镜像删不掉，并提示类似错误，说明有已停止但未删除的容器在引用它。此时要：
- 查出依赖该镜像 ID 的容器：
docker ps -a --filter "ancestor=IMAGE_ID" -q - 批量删掉这些容器：
docker rm $(docker ps -a --filter "ancestor=IMAGE_ID" -q) - 再试
docker image prune或docker rmi IMAGE_ID
不要直接用 -f 强删，避免残留元数据或损坏本地存储状态。
