笔者在服务器上执行 docker images 时，发现列表里堆了一排 <none> 镜像，占用从 511 MB 到 826 MB 不等。它们既没有仓库名，也没有标签，看起来像“幽灵”。这篇文章记录笔者如何定位根源并清理掉它们。

01 | none 镜像从哪来

<none>:<none> 常见于以下场景：构建新镜像时旧层被顶替（产生悬空镜像）、镜像被重新打标签后原标签被移走、多阶段构建的中间层、构建失败残留等。其中悬空镜像（dangling）通常可被 docker image prune 清理，而无标签镜像不一定。

笔者环境里，docker image prune -f 能清掉大部分悬空镜像，但有一条始终清不掉：

<none>  <none>  d989eed1eb19  8 days ago  825 MB

它反复出现，说明它可能并非能被 prune 直接清理的普通悬空层，需要进一步排查是否仍被容器引用，或是否被其他镜像作为父层依赖。

下面这张图概括了 none 镜像的两种来源，以及它们与“能否被 prune 清理”之间的关系：

flowchart TD A["docker images 出现 <none>:<none>"] --> B{来源判断} B -->|"构建新镜像，旧层被顶替"| C["悬空镜像 dangling"] B -->|"重新打标签，旧标签被移走"| D["无标签镜像"] C --> E{是否被容器引用} D --> E E -->|"无任何容器引用"| F["docker image prune -f 可清理"] E -->|"被停止的容器引用"| G["prune 跳过，删不掉"] G --> H["需先 docker rm 容器，再 docker rmi 镜像"]

02 | 为什么 prune 删不掉

docker image prune 默认只清理没有被任何容器引用的悬空（dangling）镜像；加 -a 后会删除所有未被任何容器使用的镜像（包括有标签但未被使用的镜像）。如果某个已停止的容器仍然指向这个镜像，prune 就会跳过它。

笔者检查后发现，根源是一个已经停止的容器 ontoforge_app_1。容器虽然停了，但它引用的镜像 ID 正是 d989eed1eb19，于是这个 none 镜像被“锁”住了。

从清理前后的对比可以更直观地看到这条“顽固”镜像的处境：

03 | 两步清理

思路很简单：先删掉占用镜像的容器，再删镜像。注意：删除容器前请确认该容器不再需要，并检查是否有需要保留的数据卷或挂载数据；生产环境建议先备份或在测试环境验证。

docker rm ontoforge_app_1
docker rmi d989eed1eb19

执行 docker rm 后，容器被移除；再执行 docker rmi，镜像及其依赖层被逐层删除，输出了一长串 Deleted: 记录。再次执行 docker images，那条 825 MB 的 none 镜像已经消失。如果 docker rmi 报错提示镜像仍被引用，可先用 docker ps -a --filter ancestor=d989eed1eb19 查找并处理相关容器。

整个清理流程可以归纳为下面几步：

flowchart LR A["docker images<br/>发现 none 镜像"] --> B["docker image prune -f<br/>批量清理悬空镜像"] B --> C{"目标 none 镜像<br/>是否仍存在"} C -->|"已删除"| D["清理完成"] C -->|"仍存在"| E["docker ps -a<br/>查找引用它的容器"] E --> F["docker rm 容器名"] F --> G["docker rmi 镜像ID"] G --> D

04 | 小结

遇到删不掉的 none 镜像，不要反复 prune。先确认是否有停止的容器还在引用它；确认该容器不再需要后，用 docker rm 清掉容器，再用 docker rmi 删除镜像即可。日常维护中，定期清理停止的容器，能避免这类镜像长期占着磁盘。

关注我，和AI一起成长~