docker system prune -a 会删除已停止容器、所有未被引用的镜像、未被使用的自定义网络及BuildKit构建缓存，加--volumes才删数据卷；误删网络导致容器断连，因自定义bridge网络若无容器attach即被判定闲置。
docker system prune -a 会删掉哪些东西
它不是只清镜像，而是四类资源一并处理：docker container prune（已停止容器）、docker image prune -a（所有未被容器引用的镜像，含带 tag 的）、docker network prune（未被任何容器使用的自定义网络）、docker builder prune -f（BuildKit 构建缓存）。默认不碰数据卷，加 --volumes 才会触发 docker volume prune -f。
为什么删完后容器突然连不上网络
因为 docker system prune -a 会清理未被容器使用的网络，而“未被使用”指当前没有任何容器 attach 到该网络上。常见踩坑点：
- 你手动创建了
docker network create mynet，但某容器启动时没显式指定--network mynet，而是用了默认bridge，那mynet就会被判定为闲置并删除 - 多个容器共用一个自定义网络，但其中某个容器被停掉又没删，其余容器仍在运行——只要所有容器都还 attach 着，网络就不会被删；但若你先
docker stop全部容器，再执行prune -a，网络就没了 - Swarm 模式下，overlay 网络不会被
prune清理，但 standalone 模式下的自定义 bridge 网络非常危险
加 --volumes 是不是更彻底
是，但代价是真实数据丢失风险。加 --volumes 后，docker volume prune -f 会删除所有未被任何容器声明使用的卷，包括那些你手动创建、但暂时没挂载到运行容器上的卷。注意：
-
docker volume ls能看到所有卷，但无法直接判断“是否正在被使用”，得结合docker ps -a --format "{{.Names}} {{.Mounts}}"手动核对 - 卷名里带
_data或postgres这类关键词的，大概率存着业务数据，别靠猜，先docker volume inspect vol-name看Mountpoint路径，去宿主机确认内容 - CI/CD 流水线中自动跑
system prune -a --volumes --force是高危操作，建议拆成builder prune+image prune -a+container prune -f分步执行
替代方案：避免误删网络的最小安全清理组合
如果你只想清镜像和构建缓存，又怕网络被连带干掉，就别用 system prune -a。改用这三个命令按顺序执行：
-
docker builder prune -f：清理 BuildKit 缓存，常占数 GB，且完全不影响运行时 -
docker image prune -af：删所有未被容器引用的镜像（含带 tag 的），比prune更激进，但不碰网络 -
docker container prune -f：清掉已停止容器，释放内存和元数据开销
这三者加起来能释放 90% 以上的冗余空间，且网络、卷、运行中容器全都不受影响——这才是日常维护最稳的节奏。
