悬挂镜像是docker build覆盖标签的自然结果，应通过docker image prune自动安全清理，并在CI末尾嵌入该命令；源头防控需禁用latest覆盖、启用--rm和多阶段构建。
持续集成中成千上万的悬挂镜像（<none>:<none>）不是异常，而是构建机制的自然结果：每次 docker build -t app:latest . 都会让前一个 app:latest 失去标签，变成无引用、无标签的中间层——它们仍占磁盘，但无法被直接识别或管理。解决关键在于“自动识别 + 安全清理 + 构建源头防控”，而非事后手动删。
快速识别和安全清理悬挂镜像
悬挂镜像只应由 docker image prune 处理，它专为此类镜像设计，不会误删带标签镜像或共享层：
-
docker images -f "dangling=true"：确认当前有多少悬挂镜像（REPOSITORY 和 TAG 全为<none>） -
docker image prune -f：强制清理所有悬挂镜像，CI 脚本中可直接使用 - 该命令底层会检查镜像层是否被其他镜像复用——若被复用，仅解除悬挂状态，不删除数据层，安全可靠
在 CI 流水线中嵌入自动清理环节
把清理变成构建流程的固定步骤，避免堆积：
- 在每个 job 的末尾添加：
docker image prune -f || true（加|| true防止无悬挂镜像时命令失败中断流水线） - GitLab CI 示例：
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
- docker image prune -f
从构建源头减少悬挂镜像产生
预防比清理更高效：
- 禁用重复覆盖
latest：改用语义化版本（如app:v1.2.3）或 Git Commit ID（app:$(git rev-parse --short HEAD)） - 构建时加
--rm参数：docker build --rm -t app:dev .，自动清理中间容器（间接减少冗余层） - 启用多阶段构建：将编译环境与运行环境分离，最终镜像不包含构建工具和中间产物，大幅降低悬挂层数量
应对极端堆积场景的紧急释放
当悬挂镜像已达数千个、prune 执行缓慢时，可补充以下操作：
- 先清理构建缓存：
docker builder prune -f（常占数 GB，且与悬挂镜像高度重叠） - 再执行：
docker system prune -f --filter "until=24h"（清理 24 小时内未使用的全部资源，含网络、构建缓存、悬挂镜像） - 慎用
docker image prune -a -f：它会删掉所有未被容器引用的带标签镜像（包括你保留的历史版本），仅建议在全新构建节点或测试环境使用
