docker image prune 默认只删除 dangling 镜像（repository 和 tag 均为且无任何引用），不删带标签的闲置镜像；需加 -a 参数（如 docker image prune -a -f）才能清理所有未被任何容器引用的镜像，包括带标签但未使用的镜像。
docker image prune 默认只删 dangling 镜像，不是“所有无用”
执行 docker image prune 后发现磁盘空间几乎没变，这是最常见现象。它默认只清理 dangling=true 的镜像——即 REPOSITORY 和 TAG 都为 <none></none>、且不被任何容器或其它镜像引用的层。这类镜像通常来自构建时没加 -t、或 docker build --no-cache 产生的中间残留。
真正想清掉“所有未被容器使用的镜像”，包括带标签但闲置的（如 myapp:v1.2 已停用半年），必须加 -a：
-
docker image prune -a -f：删所有未被任何容器FROM或run的镜像（含带名的） - 注意：若某镜像是另一镜像的基础层（如
ubuntu:22.04是你自定义镜像的FROM），Docker 会自动保留它，不会误删 - 别用
docker rmi $(docker images -q)这类暴力命令，它不检查引用关系，可能删掉正在运行容器依赖的镜像
docker volume prune 只删“未被任何容器使用”的卷
docker volume prune 的判断逻辑很直接：只要当前没有容器在 docker run 时通过 -v 或 --mount 显式挂载该卷，就认为它“未被使用”。它不管这个卷是不是你手动 docker volume create 出来的，也不管里面有没有重要数据。
容易踩的坑：
- 某些调试容器退出后，卷仍保留但不再挂载——
prune会删掉它，且不可恢复 -
docker volume prune -a并不存在；所谓“删所有卷”只能靠docker volume rm $(docker volume ls -q)，但风险极高，慎用 - 若卷被命名容器隐式引用（比如 compose 文件里定义了
volumes:但服务没启动），prune不会删它——因为它仍算“被声明使用”
为什么 docker system prune -a 有时反而更安全？
单独跑 docker image prune -a 和 docker volume prune 看似可控，但实际容易漏掉关联资源。比如一个废弃镜像对应的构建缓存、网络、或它曾启动过的已停止容器，都还在占空间。
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
docker system prune -a -f --volumes 虽然激进，但它是一致性清理：
- 删所有已停止容器（不含 running/paused）
- 删所有未被任何容器引用的镜像（含带标签的）
- 删所有未被任何容器挂载的卷（
--volumes必须显式加） - 删所有未被使用的网络和构建缓存
关键点：它不会删正在运行的容器，也不会删被 docker run -d 启动后仍在后台跑的容器所依赖的资源。真正危险的是漏看 --volumes 这个开关——不加它，卷一个都不会动。
虚悬镜像和废弃卷的真实定位方式
别全信 prune 命令的“自动识别”。当磁盘告警且 docker system df 显示总用量远高于 active 用量时，大概率是底层有 dangling 层或 orphaned 卷没被统计到。
手动确认更可靠：
- 查虚悬镜像：
docker images -f "dangling=true"，输出全是<none></none>行才对 - 查疑似废弃卷：
docker volume ls -q | xargs -I{} sh -c 'echo {}; docker volume inspect {} 2>/dev/null | grep -q "Mountpoint"'，再结合du -sh /var/lib/docker/volumes/*看大小 - 查构建缓存残留：
docker builder prune --dry-run，常能暴露出几十 GB 的隐藏占用
最易被忽略的是容器日志——它们不归 prune 管，但 /var/lib/docker/containers/**/json.log 可能单个就上百 MB。清理前先看 ls -Sh /var/lib/docker/containers/*/json.log | head -5。
