docker images显示镜像总大小，docker history查看各层标称大小但含“虚胖”，docker system df -v统计真实磁盘占用，dive检测被删除却未释放的空间。
直接用 docker images 可看整体镜像大小，但要查各层占用空间，得结合 docker history、docker system df -v 和 dive 等工具交叉验证——因为单条命令无法完整反映层的真实磁盘开销。
查看镜像总大小和基础分层信息
运行以下命令列出本地所有镜像及其大小：
docker images
输出中 SIZE 列即为该镜像的总大小（含所有只读层 + 可写层元数据）。再加 --digests 可显示镜像摘要，便于后续精准匹配：
docker images --digests
接着用 docker history 查每层构建指令和标称大小：
docker history <image_id or name:tag></image_id>
注意：这里显示的 SIZE 是该层在构建时新增内容的估算值，不包含被覆盖或删除但未真正释放的文件（即“虚胖”层），所以不能完全代表磁盘实际占用。
定位真正占用磁盘的大层
docker system df -v 是最可靠的方式，它直接读取存储驱动底层统计：
- 运行
docker system df -v，找到 Layers 表格中 Size 最大的几行 - 记下对应 Layer ID 的前 8 位（如
sha256:abc12345...→abc12345） - 用该前缀反查归属镜像：
docker image ls -a --no-trunc | grep abc12345
或更准一点：docker image inspect $(docker image ls -q) 2>/dev/null | jq -r 'select(.RootFS.Layers[] | contains("abc12345")) | .Id'
确认镜像后，再用 docker history 对齐具体哪条 COPY 或 RUN 引入了大文件。
识别“删了但没真释放”的虚胖层
比如某层执行了 RUN rm -f large.log，docker history 可能显示该层 0B，但它依赖的上层仍存着这个日志文件。这类问题需靠 dive 检测：
- 安装 dive：
sudo apt install dive（Debian/Ubuntu）或从 GitHub Release 下载 - 运行：
dive <image_id></image_id> - 进入后按 Ctrl+L 切换到“仅本层变更视图”，绿色是新增文件（重点关注大路径），橙色是被修改/复制过的文件（存在双倍空间风险）
- 右侧会统计 Wasted space，即已被上层写入、又被本层删除或覆盖却仍占空间的部分
快速脚本辅助分析（需 jq）
若想一键列出某镜像所有层的已知大小（适用于顶层可 inspect 的情况）：
docker image inspect <image_id> -f'{{range .RootFS.Layers}}{{.}} {{end}}' | \
xargs -n1 | \
awk '{print "sha256:" $1}' | \
xargs -I{} sh -c 'echo "$(docker image inspect {} 2>/dev/null | jq -r ".[0].Size // 0") bytes {}"' | \
sort -nr | head -10</image_id>
但注意：底层 layer 的 inspect 多数返回空，因此该结果仅供参考；真正落地仍推荐以 docker system df -v 为准。
