悬空层是未被任何镜像或容器引用的中间层，可安全清理；执行 docker image prune -f 可强制删除所有真正无标签、无引用（REPOSITORY 和 TAG 均为 <none>）的悬空镜像，且不误删有标签镜像或运行中容器依赖的镜像。
悬空层（dangling layers）本质上不是“被占用”的——它们恰恰是未被任何镜像或容器引用的中间层，所以才能被安全清理。所谓“被占用”通常是一种误解：如果你执行 docker image prune 提示某些镜像删不掉，那大概率是因为它们其实不是悬空镜像，而是有标签、或正被某个已停止但未删除的容器引用着。
确认是不是真悬空镜像
先明确目标：只清理真正无标签、无引用的镜像（即 REPOSITORY 和 TAG 都显示为 <none>）。运行以下命令查看：
-
docker images -f "dangling=true"—— 只列出悬空镜像（最准确） -
docker images | grep "<none>"—— 快速筛查，但可能漏判或误判（比如带标签但 ID 重复的）
强制删除悬空镜像的标准命令
确认无误后，直接用官方推荐方式一键清理，无需手动 rmi：
-
docker image prune -f—— 强制删除所有悬空镜像，不提示确认 - 等价写法：
docker image prune --force
⚠️ 注意：这个命令不会**删除有标签的镜像**，哪怕它没被运行，也不会动；也不会删正在运行/已创建但停着的容器所依赖的镜像。
为什么有时“删不干净”？常见原因和对策
如果 docker image prune -f 后仍有 <none> 镜像残留，大概率是以下情况：
-
被已停止的容器引用：用
docker ps -a查看，若有旧容器存在，先docker rm [CONTAINER_ID]或直接docker container prune -f -
构建缓存残留（非镜像层）：中断
docker build后产生的中间缓存不归image prune管理，需单独清理：docker builder prune -f -
镜像被其他镜像作为父层引用：即使显示
<none>，只要它是某带标签镜像的底层，就不会被删 —— 这属于正常设计，不该强删
不建议的“暴力清理”方式
绕过 Docker 管理机制的手动命令（如 docker rmi $(docker images -q -f dangling=true)）理论上可行，但风险更高：
- 若管道中 ID 为空，
rmi会报错甚至误删其他资源 - 无法触发 Docker 内部的引用计数校验，可能破坏镜像完整性
- 不如
prune命令健壮、可审计
日常维护请坚持用 docker image prune -f，它才是 Docker 官方定义的、安全可靠的悬空镜像清理方式。
