镜像被已停止容器引用时，docker rmi 会报“image is being used by stopped container”错误；正确做法是先用 docker ps -a 查看并 docker rm <container_id> 清理相关容器，再执行 docker rmi 删除镜像。
镜像被容器引用却强行删除
停止的容器仍会锁定其镜像，哪怕状态是 exited，执行 docker rmi 也会报错“image is being used by stopped container”。直接加 -f 强制删除，可能造成后续启动失败或日志丢失。
正确做法是先清理容器：
- 列出所有已退出容器：
docker ps -a --filter "status=exited" --format "{{.ID}} {{.Image}} {{.Status}}" - 按需删除：
docker rm <container_id>（不建议无差别docker rm $(docker ps -aq)） - 再删镜像：
docker rmi nginx:1.21
误删悬空镜像以外的“未打标”中间层
悬空镜像（dangling=true）是安全清理项，但有些镜像虽无标签，却是多阶段构建中某阶段的实际产物，或被其他镜像隐式依赖。盲目运行 docker image prune -a 可能导致下次构建变慢甚至失败——因为缓存层没了。
推荐分步验证：
- 先看哪些真悬空：
docker images -f "dangling=true" - 干跑预览：
docker image prune -f --dry-run - 只清悬空：
docker image prune -f（默认不带-a）
忽略构建缓存和 BuildKit 占用
很多人只盯着 docker images，却不知道 docker builder prune 才管构建过程中的中间镜像、缓存层和元数据。尤其启用 BuildKit 后，一次失败构建也可能留下数 GB 缓存。
日常维护建议：
- 查构建缓存大小：
docker builder du -v - 清理未使用缓存：
docker builder prune -f - CI/CD 节点可设阈值自动触发：
docker system df查总用量，超 80% 时执行docker builder prune -f && docker image prune -f
远程仓库镜像删了但本地磁盘没释放
在 Harbor 或私有 Registry 中删掉一个 tag，只是移除了 manifest 引用；底层 blob 数据仍存在，直到手动触发垃圾回收（GC）。此时 docker system df 显示的空间不会减少。
关键操作顺序：
- 调 API 删除指定 tag（如 Harbor 的
/api/v2.0/projects/xxx/repositories/yyy/artifacts/zzz） - 登录仓库管理后台，手动点击 “Garbage Collection” 或执行命令：
harbor-core gc - 等待 GC 完成后，再检查磁盘空间
