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>悬空镜像（无标签、无容器引用的 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，阻断缓存无限膨胀链
