docker rm仅删除容器本身，不清理底层读写层、悬空镜像、构建缓存及overlay2小文件，易致inode耗尽；应优先用docker container prune -f批量清除已停止容器及其关联层，并配合docker image prune -f和docker builder prune -f清理悬空镜像与构建缓存。
直接用 docker rm 无法清理元数据碎片，它只删除容器本身，不处理底层存储层、镜像缓存或文件系统级残留。元数据碎片主要来自频繁启停产生的大量已停止容器、悬空镜像层、构建缓存中间层，以及未被回收的读写层（container layer）——这些都堆积在 /var/lib/docker 下，导致 inode 耗尽或 ext4 文件系统碎片化，即使磁盘空间没满，也会报 “no space left on device”。
先定位碎片源头
运行以下命令查看真实瓶颈：
-
docker system df -v：看 Images、Containers、Build Cache 各自的 RECLAIMABLE 空间，尤其关注 Containers 行的 “97% 可回收” 类提示 -
df -i /var/lib/docker：检查 inode 使用率，若 >95%，说明是元数据（小文件）爆炸，不是大文件占空间 -
find /var/lib/docker/overlay2 -maxdepth 2 -type d -name "diff" | wc -l：统计 overlay2 的 diff 目录数量（每个已停止容器可能留一个），超 5000 个就属高碎片风险
针对性清理已停止容器及其关联层
docker rm 单条命令只能删一个容器，对大规模残留无效。应使用批量安全清理：
-
docker container prune -f：一键删所有已停止容器，并自动回收其读写层（overlay2/diff/目录） - 加
--filter "until=24h"可限定只删 24 小时内退出的容器：docker container prune -f --filter "until=24h" - 避免用
docker rm $(docker ps -aq)，它不清理关联的网络、卷、构建缓存，且易误删运行中容器（除非加-f，但极不推荐）
连带清理悬空镜像与构建缓存层
频繁构建/启停常伴随大量中间镜像和 BuildKit 缓存，它们同样生成海量小目录，加剧元数据压力：
-
docker image prune -f：清除所有<none>:<none></none></none>悬空镜像（即无标签、无容器引用的层） -
docker builder prune -f：清空 BuildKit 构建缓存（Docker 18.09+ 默认启用），这部分常占数 GB 且全是小文件 - 如需更激进清理（确认无后续构建需求）：
docker builder prune -a -f
防止碎片再生的关键配置
清理只是补救，治本要从运行习惯入手：
- 启动容器时加
--rm参数（如docker run --rm nginx），容器退出后自动清理，不留下 stopped 状态 - 构建镜像时加
--no-cache或定期执行docker builder prune，避免缓存无限膨胀 - 检查
/etc/docker/daemon.json，开启自动 GC（如"features": {"buildkit": true}配合定期 prune）
不复杂但容易忽略：元数据碎片本质是“小文件太多”，核心对策就是删干净已停止容器 + 悬空层 + 构建缓存，再配合 --rm 养成习惯。清理后建议重启 dockerd：sudo systemctl restart docker，让 overlay2 文件系统重新整理 inode 分配。
