docker磁盘空间告警主因是已停止容器、悬空镜像、buildkit缓存及overlay2 diff目录等小文件堆积导致inode耗尽，而非volume本身；应优先执行docker container prune -f、docker image prune -f和docker builder prune -f组合清理，并通过docker system df -v与df -i /var/lib/docker定位真实瓶颈。

volume 本身不直接产生元数据碎片，真正导致 /var/lib/docker 下 inode 耗尽、ext4 小文件爆炸的，是频繁启停容器所遗留的已停止容器、悬空镜像层、buildkit 构建缓存、overlay2 diff 目录——这些都堆在 volume 管理范围之外的 docker 存储路径里。volume（如 mysql-data）只要命名固定、挂载正确，数据始终安全，但它的“邻居”却在悄悄拖垮系统。

先确认是不是真问题：查清瓶颈源头

别急着删，先运行三行命令定位真实瓶颈：

• docker system df -v：重点看 Containers 行的 RECLAIMABLE 比例，若超 90%，说明大量已停止容器没清理
• df -i /var/lib/docker：inode 使用率 > 95%？那就是小文件（overlay2/diff/、build cache 目录）撑爆了元数据空间
• find /var/lib/docker/overlay2 -maxdepth 2 -type d -name "diff" | wc -l：结果超 5000？每个 diff 目录大概对应一个已停止容器，属于高风险状态

批量清理已停止容器及其读写层

docker rm 单条命令无效，它只删容器对象，不回收 overlay2 的 diff 和 merged 目录。必须用 Docker 原生批量清理工具：

• docker container prune -f：一键清除所有已停止容器 + 自动回收其关联的读写层（即 overlay2/diff/xxx 目录）
• 加时间过滤更安全：docker container prune -f --filter "until=12h"，只删 12 小时内退出的容器，避免误清长期运行的服务
• 严禁用 docker rm $(docker ps -aq)：它跳过网络、卷、构建缓存的联动清理，且极易误删正在运行的容器

连带清理悬空镜像与构建缓存

频繁构建/启停常伴生大量中间层和 BuildKit 缓存，它们全是小目录，对 inode 压力极大：

• docker image prune -f：清除所有 <none>:<none></none></none> 悬空镜像（无标签、无容器引用的 layer）
• docker builder prune -f：清空 BuildKit 默认缓存（Docker 18.09+ 启用），这部分常占数 GB 且全是 subdirectory
• 若确定后续无构建需求，可激进执行：docker builder prune -a -f

从源头防止碎片再生

清理是补救，治本靠规范启动和构建习惯：

• 所有临时测试容器加 --rm 参数：docker run --rm -v myapp-data:/data nginx，退出即删，不留 stopped 状态
• 生产服务用命名卷并显式创建：docker volume create myapp-data，再挂载；避免用 -v /host/path 或匿名卷，后者每次 run 都新建 diff 目录
• CI/CD 构建镜像时，加 --no-cache 或定期 docker builder prune，阻断缓存无限膨胀链