docker history --format "{{.size}}\t{{.createdby}}" your-image:latest | sort -hr | head -15可按体积倒序列出各层大小及对应指令，直观识别不合理膨胀层；需结合dive分析“虚胖”文件和copy-on-write隐式占用，并用docker system df -v交叉验证真实层大小。
直接用 docker history 加排序就能直观看出各层体积差异，关键不是只看“大小数字”，而是结合构建指令判断哪一层不合理膨胀。
用 docker history 按体积倒序排列
执行以下命令，把每层大小和对应指令一起列出，并按体积从大到小排序：
docker history --format "{{.Size}}\t{{.CreatedBy}}" your-image:latest | sort -hr | head -15
你会看到类似输出：
450MB /bin/sh -c apt-get update && apt-get install -y curl256MB /bin/sh -c npm install --production
10MB /bin/sh -c #(nop) COPY . .
明显偏大的层（如几百 MB）就是首要怀疑对象。注意：Size 显示的是该层新增内容的净大小，但不反映 copy-on-write 带来的隐式占用。
识别“虚胖”层：被删文件仍占空间
Docker 分层机制下，某层 RUN rm -f big.log 并不会真正释放空间——因为日志文件是在上层写入的，删除操作只是在当前层标记“已删”，原始文件仍保留在上层中。
- 这种层往往显示体积很小（比如 0B 或几 KB），但实际拖累整体镜像——需配合
dive查看“Wasted space”统计 - 常见于：
RUN tar -xzf archive.tgz && rm archive.tgz—— 压缩包虽删，解压内容已落盘，且压缩包本身还留在那一层 - 对比时重点看：同一路径是否在前几层出现、又在后续层被覆盖或删除
交叉验证层 ID 与真实存储大小
docker history 显示的是构建链路，但底层 layer 的实际磁盘占用需查 docker system df -v：
- 运行
docker system df -v，找到 “Layers” 表中 Size 最大的几行，记下 Layer ID 前 8 位 - 再执行：
docker image ls -a --no-trunc | grep <layer_id></layer_id>，反查归属镜像 - 确认后，用
docker history <image_id></image_id>对齐具体指令——避免因镜像复用导致的误判
用 dive 辅助层间差异可视化
dive 能把层间增删改关系摊开来看：
- 左侧按层列出真实大小，点击某层可展开右侧文件树
- 绿色 = 当前层新增（重点关注大文件路径）
- 橙色 = 上层已有、本层修改（说明被复制过一次，存在双倍风险）
- 按 Ctrl+L 切换为“仅本层变更视图”，快速比对两层之间到底多了什么、删了什么
