先执行docker system df查看全局占用，重点关注Images的RECLAIMABLE值；再用docker images --format排序定位大镜像；最后分步清理悬空镜像、停用容器和构建缓存，避免误删运行资源。
遇到 Docker 镜像占满磁盘空间，别急着删文件，先定位“谁在吃空间”——核心是分层排查：先看整体分布，再钻进镜像本身，最后确认是否可安全清理。
一、用 docker system df 快速掌握全局占用
登录服务器后第一件事就是执行：
docker system df
它会清晰列出四类资源的占用情况：
- Images：所有本地镜像总大小 + 可回收空间（重点看 RECLAIMABLE 列，比如显示 3.212GB (55%)，说明近一半镜像是悬空或未被引用的）
- Containers：已停止容器的可写层仍占空间，哪怕容器没运行
- Local Volumes：命名卷数据，SIZE 是真实磁盘占用，但 RECLAIMABLE 常为 0（因为卷默认不自动清理）
- Build Cache：BuildKit 构建留下的中间层，常被忽略，却可能达 GB 级
如果 Images 的 RECLAIMABLE 值很高，基本可以锁定问题在镜像堆积。
二、定位具体是哪些镜像在占大头
执行以下命令按大小倒序列出所有镜像：
docker images --format "{{.Repository}}:{{.Tag}}\t{{.Size}}" | sort -k 2 -h -r
你会看到类似：
nginx:latest 456MB
redis:7.0.14 189MB
<none>:<none> 124MB
mysql:8.0 1.2GB
重点关注：
- 大量 <none>:<none> 镜像（悬空镜像），通常是构建失败、tag 覆盖或手动删除 tag 后残留
- 同一仓库多个旧版本（如 app:v1.2、app:v1.3、app:v1.4 全部存在，但只用最新版）
- 单个镜像异常巨大（超过 1GB），可能是构建时 COPY 了日志、缓存或调试文件
三、安全清理：从高危到低风险逐步操作
清理不是一股脑 docker system prune -a，要分步控制风险：
- 删掉所有已停止容器：docker container prune -f（释放 Containers 可写层）
- 删掉所有悬空镜像：docker image prune -f（只清 <none>，不影响正在用的镜像）
- 删掉未被任何容器引用的镜像（不含悬空）：docker image prune -a -f --filter "until=72h"（加时间过滤更稳妥）
- 若确认某镜像完全不用，直接删：docker rmi nginx:old-tag（支持 ID 或 repo:tag）
注意：docker system prune -a 会删掉所有未使用的镜像、容器、网络和构建缓存，慎用于生产环境。
四、预防下次再爆：从根源减少镜像膨胀
光清理不治本。日常要注意：
- 构建时用多阶段构建（multi-stage），避免把编译工具、源码、测试包打进最终镜像
- 拉镜像明确指定 tag，不依赖 latest；定期检查并清理旧 tag
- 在
/etc/docker/daemon.json中配置{"log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"3"}}，防止容器日志无限增长 - 对长期运行的测试机，建议设置定时任务：
0 3 * * * docker image prune -f && docker builder prune -f
不复杂但容易忽略。
