执行 docker image prune 或 system prune -a 卡死，主因是守护进程假死、overlay2 元数据锁冲突、镜像引用环损坏或内核资源竞争；应先检查 daemon 状态与日志，再分步手动清理。
执行 docker image prune 或 docker system prune -a 时卡死或长时间无响应，不是镜像太多那么简单——它往往指向底层存储驱动、元数据锁、守护进程状态或内核资源竞争等深层问题。这类故障在生产环境尤其危险，因为清理命令本身会阻塞其他 docker 操作。
确认 Docker daemon 是否处于健康阻塞态
清理命令卡住，第一步不是查镜像，而是确认 Docker 守护进程是否“假死”：
- 运行
systemctl status docker，观察 Active 状态是否为 active (running)，且没有反复 restarting - 执行
docker info—— 若命令也卡住或超时，说明 daemon 已无法响应 API 请求，大概率是存储层挂起或 goroutine 死锁 - 检查日志关键线索：
journalctl -u docker.service --since "10 minutes ago" | grep -E "(deadlock|timeout|overlay|fuse|lock)"
排查 overlay2 存储驱动元数据锁冲突
使用 overlay2 驱动时，prune 需遍历 /var/lib/docker/overlay2/l（链接目录）和 /var/lib/docker/image/overlay2/imagedb/content/sha256/，若某层被进程长期 hold（如未完成的构建、崩溃的容器写入），就会触发内核级目录锁等待：
- 用
lsof +D /var/lib/docker/overlay2查看哪些进程正在访问 overlay2 目录（重点关注containerd-shim、buildkitd或残留的rsync/cp进程） - 检查是否有异常挂起的 build 缓存：运行
docker builder ls，若列表中存在 STATUS: BUILDING 但无对应容器，说明 buildkit 卡在中间步骤，需手动清理：docker builder prune --all --force - 临时禁用 overlay2 的 mount 优化（仅调试）：
echo 'overlay2.override_kernel_check=1' | sudo tee -a /etc/modprobe.d/overlay.conf && sudo modprobe -r overlay && sudo modprobe overlay
验证镜像元数据完整性与引用环
Docker 的镜像图谱（image graph）依赖 imagedb 和 layerdb 的双向引用。若因强制中断、磁盘错误或并发操作导致引用不一致，prune 在计算“可回收性”时会陷入无限递归或等待：
- 导出当前镜像关系快照：
docker image ls --format '{{.ID}}\t{{.Repository}}:{{.Tag}}' > images.list；再用docker system df -v对比显示的镜像数是否明显少于images.list行数（暗示元数据丢失） - 检查是否存在悬空层但无对应镜像 ID：
find /var/lib/docker/image/overlay2/layerdb/sha256/ -mindepth 1 -maxdepth 1 -type d | wc -l与docker image ls -q | wc -l对比，差值过大即存在“孤儿层” - 运行轻量校验（不触发 prune）：
docker image inspect $(docker image ls -q | head -1) 2>/dev/null || echo "inspect failed on first image"，若失败，说明该镜像元数据已损坏
绕过默认 prune 机制进行安全清理
当标准命令持续卡死，可分步手动释放空间，避免全局锁：
- 只删明确无用的
<none>镜像（不触 layerdb）：docker rmi $(docker images -f "dangling=true" -q 2>/dev/null) - 逐个清理构建缓存条目（比
builder prune更可控）：docker builder du -v | awk '$1 ~ /^[0-9]+[.][0-9]+[MG]B$/ {print $2}' | xargs -r docker builder rm - 清空日志文件（常被忽略的磁盘杀手）：
find /var/lib/docker/containers/ -name "*.log" -size +100M -exec truncate -s 0 {} \; - 终极手段：停 daemon 后手动清理（需业务允许停机）：
sudo systemctl stop docker && sudo rm -rf /var/lib/docker/image/overlay2/imagedb/content/sha256/* && sudo systemctl start docker（注意：此操作会丢失所有镜像记录，仅保留容器层，重启后需重新 pull）
