是预期行为：docker rmi 仅删除镜像元数据，不影响正在运行的容器；容器依赖已加载的镜像层，停止后才真正释放磁盘空间。
docker rmi 删除镜像后容器还在？这是预期行为
docker rmi 只删镜像，不碰任何容器。哪怕某个容器正用着被删的镜像，它照样能 start、exec、甚至 commit 新镜像——因为容器运行依赖的是已加载的镜像层（layer），不是镜像元数据本身。
所以“删镜像没清掉环境”，不是 bug，是设计如此。
- 容器未停止时，
docker rmi会拒绝删除其 base 镜像（报错：Error response from daemon: conflict: unable to remove repository reference ... (must force)） - 强制加
-f也只删元数据，不影响正在运行的容器 - 镜像被多个容器共用时，删一次不会真正释放磁盘空间，得等所有引用都消失
先停再删：docker stop + docker rm 是清理容器的标准组合
停用并删除容器必须分两步，没有“一键删容器+镜像”的默认命令（docker system prune -a 是例外，但太粗暴）。常见误操作是只跑 docker rm 却忘了 stop，结果报错：Error response from daemon: You cannot remove a running container。
- 必须先
docker stop，再docker rm - 想跳过手动 stop，可用
docker rm -f，它隐式执行 stop + rm（但别在生产环境无脑用） - 批量删所有已退出容器：
docker rm $(docker ps -q -f status=exited)；注意docker ps -q默认只列运行中容器，得加-f status=exited或-a -
docker rm不会删 volume，除非显式加-v参数（且仅删匿名卷）
想彻底清空？docker system prune -a 要谨慎评估影响
这个命令会同时删：所有已停止容器、所有 dangling 镜像、所有未被容器引用的网络、所有构建缓存。但它不会删命名卷（named volume）和已挂载的绑定卷（bind mount）——这点常被忽略，导致磁盘没真正释放。
- 运行前务必确认：当前没重要容器处于 exited 状态（比如数据库备份完成后的临时容器）
- 它会删所有 dangling 镜像（
: docker build中间层，删了下次构建就得重拉基础镜像 - 如果用了
--volumes参数，它会删所有未被容器引用的命名卷——但一旦删了，数据就没了，不可逆 - 替代方案更可控：
docker container prune+docker image prune -a分开执行，中间可人工确认
镜像和容器 ID 混用导致误删？记住 ID 前缀匹配规则
Docker 允许用 ID 前几位代替全 ID（如 abc123 匹配 abc123def456...），但前提是前缀唯一。如果两个镜像或容器 ID 都以 abc123 开头，docker rmi abc123 会报错：Error: No such image: abc123。
- 容器 ID 和镜像 ID 是不同命名空间，
docker rmi abc123不会误删容器，反之亦然 - 但
docker rm abc123若匹配到容器，就不会去查镜像；如果只匹配到镜像，会报错说“no such container” - 最安全做法：用
docker ps -a或docker images查全 ID，复制粘贴，或用容器名/镜像名（带 tag）代替短 ID
清理这事，关键不是命令多不多，而是搞清「谁依赖谁」：容器依赖镜像，卷独立于两者，网络又另算一层。漏掉任意一环，都可能让下次 df -h 时发现磁盘还是满的。
