Docker rmi报“conflict: unable to remove repository reference”本质是同一镜像ID存在多个tag；应先docker images --digests查重，再逐个rmi标签，而非镜像ID。
docker rmi 报错 “conflict: unable to remove repository reference”
这是最常见的镜像删除失败现象，本质不是镜像本身被占用，而是本地存在多个 docker tag 指向同一个镜像 ID。Docker 默认不允许直接删掉“还有标签挂着”的镜像层。
实操建议：
- 先用
docker images --digests查看所有标签和对应IMAGE ID，注意相同IMAGE ID是否出现多次 - 用
docker rmi逐个删掉冗余标签（比如myapp:latest、myapp:v1.2），而不是直接删IMAGE ID - 如果想批量清理未打标签的悬空镜像，用
docker image prune，它只动:
docker rmi -f 强删后仍残留镜像层
docker rmi -f 看似暴力，但其实只是解绑标签 + 标记为可回收；真正释放磁盘空间要等垃圾回收触发，或手动执行 docker system prune。
实操建议：
-
docker rmi -f后立刻运行docker system df，观察BUILD CACHE和Images下的RECLAIMABLE值是否上升 - 确认无运行中容器、构建缓存、网络或卷依赖后，再执行
docker system prune -a（加-a才会删未使用镜像） - 生产环境慎用
-a，它会清掉所有未被容器引用的镜像，包括你忘了启动但还留着的测试镜像
多阶段构建导致中间层无法被 docker rmi 清理
多阶段构建（multi-stage build）产生的中间构建器镜像（如 builder 阶段生成的临时镜像）默认没有标签，但会被后续阶段隐式引用。这些层不会出现在 docker images 列表里，却占着空间。
实操建议：
- 构建时加
--rm参数（Docker 默认开启），让构建结束自动清理中间容器；但中间镜像层仍可能残留 - 构建完立刻执行
docker builder prune（Docker 23.0+）或docker system prune --filter "type=buildcache"（旧版） - 检查
/var/lib/docker/buildkit/cache.db（BuildKit 启用时）或docker images -f "dangling=true"，找真正的悬空层
镜像被正在运行的容器引用却不报错
docker rmi 对正在运行的容器所用镜像会静默跳过，不报错也不提示，只输出类似 Untagged: xxx 或直接没反应——容易误以为删成功了。
实操建议：
- 删之前务必执行
docker ps --filter ancestor=，确认无匹配容器--format "{{.ID}}" - 如果容器是用
docker run -d启的且没指定--name，它可能只有随机名，用docker ps --no-trunc看完整IMAGE ID对比更可靠 - 删完再跑一次
docker images | grep，别只信命令返回值
最麻烦的是 BuildKit 缓存 + 多阶段 + 悬空层 + 运行中容器混在一起的情况——这时候 docker system df -v 输出的层级关系比 docker images 更真实，得一层层对 ID 才能定位到底哪块卡住了。
