应先用docker system df和docker images --format命令定位空间黑洞，再分阶段执行image/container/builder/volume prune清理，最后可选docker system prune -a -f --volumes并加--filter until=72h保障安全，辅以CI自动清理和日志限容等长效机制。
遇到宿主机磁盘突然爆满，且确认是 Docker 引起的，说明已有大量未被引用的镜像层、构建缓存或停止容器在后台持续“静默占坑”。这时候不能只靠删一两个镜像，得用一套分层递进、兼顾安全与效果的全局清理策略。
第一步：快速定位空间黑洞
先别急着删，用两行命令看清谁在吃空间：
- docker system df —— 查总账：看 Images、Containers、Volumes、Build Cache 四类资源的 SIZE 和 RECLAIMABLE（可回收量），重点关注 RECLAIMABLE >50% 的项；
- docker images --format "{{.Size}}\t{{.Repository}}:{{.Tag}}" | sort -h -r | head -10 —— 看大户：列出体积最大的前10个镜像，常会暴露重复拉取的 ubuntu:22.04、node:18-alpine 等基础镜像多个标签，或 CI 构建留下的临时镜像（如 <none>:<none>）。
第二步：分阶段精准清理，避免误伤运行服务
按风险由低到高执行，每步后建议再跑一次 docker system df 观察释放效果：
-
清悬空镜像：
docker image prune -f—— 只删无标签、无容器引用的中间层（dangling=true），零风险，通常能释放 2–5GB； -
清停用容器：
docker container prune -f—— 删除所有 exited 或 created 状态的容器及其可写层，注意：这不删运行中容器，但会丢掉其日志和临时文件； -
清构建缓存：
docker builder prune -f—— 清掉所有 docker build 产生的中间层缓存，CI 频繁构建的机器这里常藏 3–10GB 冗余； -
清未用卷（谨慎）：
docker volume prune -f—— 只删未被任何容器挂载的匿名卷；若用了命名卷（如 db-data），需手动确认是否废弃后再删。
第三步：深度清理（生产环境需评估）
若上述操作后仍剩余大量 RECLAIMABLE 空间，且确认无长期保留需求，可执行：
- docker system prune -a -f --volumes —— 一键清空所有未使用的镜像（含带标签但未运行的）、容器、网络、构建缓存、以及未挂载的卷；
- ⚠️ 注意：--volumes 是高危选项，务必提前确认卷里没有数据库数据、配置文件等持久化内容；如有，应先备份再删；
- 建议加 --filter until=72h 限定只删 3 天前的资源，留出缓冲窗口，例如：
docker system prune -a -f --volumes --filter until=72h。
第四步：堵住源头，防止反复爆满
清理只是救火，长效机制才是关键：
- 在 CI/CD 流水线末尾加入
docker builder prune -f和docker image prune -f； - 给
docker run加 --rm 参数，让容器退出后自动清理可写层； - 限制容器日志大小，在
/etc/docker/daemon.json中配置：
{"log-driver": "json-file","log-opts": {"max-size": "50m","max-file": "3"}}，重启 Docker 生效； - 定期检查
du -sh /var/lib/docker/overlay2，结合df -h监控宿主机根分区使用率。
