悬挂镜像是构建中旧标签丢失导致的:镜像，可用docker images -f "dangling=true"识别，推荐用docker image prune安全清理，预防需避免标签覆盖并采用语义化版本。
解决 Docker 镜像构建过程中产生的悬挂镜像（dangling images），核心是理解它们的成因并建立安全、可重复的清理习惯。这类镜像不是故障，而是构建机制的自然产物——比如你反复 docker build -t app:latest .，每次新构建都会让旧的 app:latest 失去标签，变成 <none>:<none></none></none>，却仍占用磁盘空间。
识别悬挂镜像：先看清再动手
运行以下命令，快速确认当前有多少悬挂镜像：
-
docker images -f "dangling=true"—— 显示完整列表（含 ID、大小、创建时间） -
docker images -f "dangling=true" -q—— 仅输出镜像 ID，方便后续脚本处理
注意：输出中所有 REPOSITORY 和 TAG 列均为 <none></none> 的行，就是目标对象。
安全清理：推荐用 docker image prune
这是专为悬挂镜像设计的标准命令，不会误删带标签的镜像或正在使用的层：
-
docker image prune—— 交互式清理，会提示确认 -
docker image prune -f—— 强制执行，跳过提示，适合脚本或 CI/CD 中自动调用
该命令只作用于 dangling=true 的镜像，底层 layer 若被其他镜像复用，也不会被删除，安全性高。
预防悬挂镜像堆积：从构建环节入手
与其频繁清理，不如减少产生：
- 构建时加
--rm参数：docker build --rm -t app:latest .，自动清理中间容器（虽不直接删 dangling 镜像，但减少冗余层） - 避免反复覆盖同一标签；改用语义化版本（如
app:v1.2.0）或 Git commit ID 打标签，保留历史可追溯性 - 在 CI 流水线末尾固定加入
docker image prune -f，形成“构建→测试→清理”闭环
进阶场景：需要连带清理未使用镜像？谨慎操作
如果发现磁盘仍吃紧，可能还有带标签但未被任何容器引用的“闲置镜像”。此时可用：
-
docker image prune -a—— 删除所有未被容器引用的镜像（含带名但不用的） -
docker image prune -a -f—— 强制执行
⚠️ 注意：该操作不可逆，执行前建议先运行 docker ps -a 确认没有需保留的停止容器（因为停止容器也会“引用”镜像）。
