docker volume prune只清理未被任何容器（含已退出）引用的悬空卷，不删正在使用的数据；它通过检查容器Mounts字段判断占用状态，Exited容器仍持有卷即受保护，不会误删。
docker volume prune 只删真正闲置的卷，不会丢正在用的数据
它只清理 dangling（悬空）卷，也就是当前没有任何容器（包括已退出的）在 Mounts 字段中引用的卷。只要容器 docker inspect 输出里还带这个卷名，docker volume prune 就跳过不碰——哪怕容器是 Exited 状态，只要没被彻底移除，卷就受保护。
常见误判点：
- 看到
docker ps -a里一堆Exited容器，以为卷可删 → 实际这些容器仍“持有”卷，prune不会动 - 卷名像
postgres_data就直接删 → 必须先docker volume inspect postgres_data看CreatedAt和挂载路径，再查业务是否还在依赖 - 用
docker system prune -a --volumes代替volume prune→ 前者会删所有未挂载卷，不管名字、不管业务上下文，风险高得多
Windows Docker Desktop 下，卷清理后 docker_data.vhdx 不缩容是正常现象
WSL2 虚拟硬盘 docker_data.vhdx 的大小不会因删卷自动收缩。你执行了 docker volume prune，宿主机上对应目录（如 C:\Users\XXX\AppData\Local\Docker\wsl\data\ 内的卷数据）确实被清空了，但 .vhdx 文件仍维持原尺寸，这是 WSL2 的设计行为，不是命令没生效。
要真正释放磁盘空间，得额外走两步：
- 在 PowerShell 中进入 WSL：
wsl -d docker-desktop-data - 运行
sudo poweroff关闭该发行版 - 回到 Windows，执行：
wsl --shutdown & diskpart /s "compact vhdx"（需提前写好 compact 脚本）或手动用 DiskPart 执行compact vdisk
跳过这一步，你会看到磁盘占用没变——不是清理失败，是 WSL 层没回收块。
想删单个卷？先确认它真“没人用”，否则 docker volume rm 会报错
docker volume rm 对使用中的卷有强保护：哪怕容器已停止，只要 docker ps -a --filter volume=xxx 有输出，或 docker inspect 的 Mounts 列表含该卷名，命令就会失败并提示 volume is in use。
安全操作链：
- 查引用：
docker ps -a --filter volume=myapp_logs - 如果返回非空，先删容器：
docker rm -f 容器ID - 再查一遍，确保无输出
- 最后执行：
docker volume rm myapp_logs
注意：匿名卷（没指定名字、由 Docker 自动生成）通常绑定在某个已删容器上，docker volume ls -f dangling=true 才能看见它们，这类卷基本可安全清理，但别批量 rm $(docker volume ls -q) —— 那会误删命名卷。
生产环境别信“一键清理”，docker system prune -a --volumes 是重置级操作
这个命令不区分卷名、不看创建时间、不检查业务逻辑，只要卷没被任何容器挂载，就全删。它等价于把整个 /var/lib/docker/volumes/（Linux）或 C:\ProgramData\Docker\volumes\（Windows）里未挂载的子目录扫掉。
真实风险场景：
- CI/CD 流水线临时起的容器用了命名卷，跑完容器自动删了，但卷留着 →
system prune会把它当闲置卷清掉 - 数据库容器停机维护中，卷没卸载，但容器状态是
Exited→volume prune保得住，system prune -a --volumes保不住 - 本地开发多个项目共用一个卷名（比如都叫
shared_cache），但只有其中一个在用 →system prune无法识别“部分活跃”，一并清除
真正保险的做法，永远是：先 docker volume ls -f dangling=true 看列表，再逐个 inspect + 人工核对，而不是靠参数开关赌运气。
