必须先删除关联容器才能成功删除镜像，因为Docker通过引用计数保护被容器（包括已停止的）占用的镜像，直接强制删除（-f）可能导致启动失败或构建缓存异常。
docker rmi 报错 “conflict: unable to remove repository reference” 怎么办
这是最常见的情况：你想删镜像，但 Docker 提示它被某个容器（哪怕是已停止的）关联着。docker rmi 默认只删“无人引用”的镜像，哪怕容器 Exited 了，只要没被显式清理，它的 Image 字段仍算作占用。
别急着加 -f 强删——它不会真正解决问题，只是跳过校验，可能留下 dangling 镜像或后续拉取异常。
- 先查谁在用：
docker ps -a --filter ancestor=IMAGE_NAME_OR_ID --format "{{.ID}} {{.Status}}" - 确认后，停并删容器：
docker stop CONTAINER_ID→docker rm CONTAINER_ID - 再试
docker rmi IMAGE_NAME_OR_ID，通常就能成功
删镜像前要不要先删 container？
不是“要不要”，而是“必须”。Docker 的镜像生命周期依赖容器元数据：只要 docker inspect CONTAINER_ID 中的 Image 字段还指向该镜像 ID，docker rmi 就会拒绝删除（即使容器状态是 Exited 或 Created）。
- 注意
docker ps -a可能漏掉某些临时容器（比如用--rm启动失败后残留的），建议配合docker system df -v看实际引用关系 - 批量清理可写小脚本：
docker ps -a --filter ancestor=IMAGE_ID -q | xargs -r docker rm，但务必确认IMAGE_ID准确，避免误删运行中服务 -
docker image prune -f不会动被容器引用的镜像，它只清 dangling 和未被任何容器/构建缓存引用的镜像
强制删除（docker rmi -f）的风险和适用场景
docker rmi -f 实际上是绕过引用检查，直接从本地存储移除镜像层。它不报错，但可能让后续操作出问题：
- 如果还有容器依赖该镜像启动（比如用
docker start），会提示No such image - 若该镜像是某个多阶段构建中间层，
docker build可能因缓存失效变慢甚至失败 - 在 CI/CD 流水线里滥用
-f，容易掩盖镜像管理混乱的问题 - 真正适合
-f的场景只有两种：确定所有容器都已销毁且无复用需求；或调试时快速释放磁盘空间，接受后续重建成本
如何避免下次再被“占用”困扰
根本不在“删”，而在“管”：让容器和镜像的生命周期对齐。
- 开发环境启动容器时，尽量加
--rm，容器退出即自动清理，不遗留引用 - CI 构建后立即用
docker image prune -f --filter "before=$(docker images -q IMAGE_NAME:latest)"清旧版（慎用，需确保没其他 job 正在拉） - 定期跑
docker system prune -f（注意它也会删网络、卷、构建缓存），比单删镜像更彻底 - 别用
latest标签做生产部署——它会让docker rmi变得不可预测，因为多个 tag 可能指向同一镜像 ID
镜像被占用不是 Docker 的 bug，是它的引用计数设计使然。越想跳过这步，后面越容易掉进 cache 错乱、pull 失败、disk full 的坑里。
