docker volume prune 是清理悬挂卷的正确命令，它能安全批量删除所有未被容器引用的悬空卷；而 docker rm 仅删除容器，对悬挂卷完全无效。
docker rm 本身不能清理悬挂卷，它只删容器。悬挂卷（dangling volumes）是容器删除后遗留的、未被任何容器引用的数据卷，它们会持续占用 /var/lib/docker/volumes 空间，导致磁盘悄悄“泄露”。真正防止空间泄露，得靠 docker volume prune 配合识别和确认步骤。
先识别哪些卷是悬挂状态
执行以下命令列出所有未被任何容器使用的卷：
-
docker volume ls -f dangling=true—— 显示所有悬空卷（Docker 20.10+ 默认行为，旧版本必须加-f dangling=true） -
docker volume ls --format "{{.Name}}\t{{.Driver}}"—— 辅助查看卷名和驱动类型，区分命名卷与匿名卷 -
docker system df -v—— 查看卷总用量，重点关注VOLUME NAME列中为
安全批量清理悬挂卷
确认列表无误后，再执行清理：
-
docker volume prune—— 交互式运行，会提示确认，适合首次操作 -
docker volume prune -f—— 跳过提示，直接删除所有悬挂卷，适合脚本或定期运维
⚠️ 注意：prune 不会动正在使用的卷（哪怕容器已停止但未 rm），也不会删命名卷——除非该命名卷确实没被任何容器挂载。
为什么不能靠 docker rm 解决？
因为数据卷生命周期独立于容器：
- 匿名卷（如
-v /data创建）：容器删了，卷若无人再挂载，就变悬挂卷 - 命名卷（如
-v mydb:/var/lib/mysql）：即使容器已删，卷仍存在，docker rm完全不碰它 - 绑定挂载（
-v /host/path:/container/path）和 tmpfs 不属于 volume 管理范围，docker volume命令对其无效
预防下次再堆积的实用做法
清理是补救，习惯才是关键：
- 启动容器时优先用命名卷，避免
-v /path这类匿名挂载 - Dockerfile 中慎用
VOLUME指令；持久化需求尽量交由运行时-v控制 - CI/CD 或自动化脚本中，
docker rm -f后，若确认卷不再需要，追加docker volume rm - 把
docker volume prune -f加入每周 cron，并配合df -h /var/lib/docker监控告警
