问题根源在于overlay2中残留未引用层，而非镜像未删净；需用docker images -f "dangling=true"和docker system df -v定位悬空层与可回收空间，再按prune顺序安全清理。
镜像删了但空间没释放，问题大概率出在 overlay2 目录里残留的未引用层，而不是镜像本身没删干净。Docker 的分层机制决定了镜像删除只移除顶层引用，底层共享层仍保留在 overlay2 中，除非明确清理悬空层。
确认是否真有残留层
运行以下命令查看是否存在 dangling（悬空）镜像层：
-
docker images -f "dangling=true"—— 列出所有未被任何镜像引用的中间层镜像（即构建缓存或废弃层） -
docker system df -v—— 查看详细磁盘使用情况，重点关注 “Reclaimable” 列，它会显示当前可被prune回收的空间量
检查 overlay2 实际占用结构
进入 Docker 数据根目录，定位真正吃空间的位置：
- 先查路径：
docker info | grep "Docker Root Dir"，通常为/var/lib/docker - 进 overlay2：
cd /var/lib/docker/overlay2 - 按大小排序看哪些目录最占空间：
du -sh * | sort -hr | head -20 - 注意：单个目录名（如
abc123.../diff）对应一个镜像层；merged是运行时挂载点，不直接占空间；真正占空间的是diff和lower子目录
关联容器或镜像验证归属
发现大目录后，别急着删，先确认它是否还在被使用：
- 查该层是否属于某个镜像：
docker image ls --no-trunc | grep abc123...（用目录前缀匹配） - 查是否被容器引用：
docker ps -a --format "{{.ID}} {{.Image}} {{.Status}}" | grep -E "(abc123|def456)" - 更准的方式是查 layer ID 映射：
cat /var/lib/docker/image/overlay2/layerdb/sha256/*/cache-id 2>/dev/null | grep abc123
安全清理的推荐操作顺序
按风险由低到高执行，避免误删：
- 清空已停止容器的日志（不删文件，只清内容）：
find /var/lib/docker/containers/ -name "*.log" -exec truncate -s 0 {} \; - 清理悬空镜像：
docker image prune -f - 清理全部未使用资源（含网络、卷、构建缓存）：
docker system prune -a -f - 若仍有大量 reclaimable 空间未释放，且确认无业务容器在用，可重启 Docker 后再执行一次 prune（部分 layer 锁定需服务重启才能解除）
