必须先删除关联容器才能成功删除镜像，因为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 的坑里。