Dive能精准定位镜像体积异常根源：左侧显示各层真实大小及变化，右侧用颜色标记新增（绿）、修改（橙）文件，标出被删除却仍占空间的“虚胖”文件，并汇总浪费空间与效率评分。
直接用 Dive 就能快速定位镜像体积异常的根源。它不是只告诉你“哪层变大了”，而是明确指出“哪些文件在哪些层里新增、修改、删除，又占了多少空间”，把 Docker 分层机制带来的隐藏浪费全摊开来看。
看每层真实占用，识别膨胀源头
Dive 左侧列出所有镜像层，每层都标有精确大小。注意两点：
- 某一层显示“135MB”，不等于它只加了135MB——可能是复制了上层的大文件再改写，触发 copy-on-write，实际多占一份空间
- 连续几层都偏大？重点检查它们对应的 Dockerfile 指令，比如 RUN apt-get install 后没清理缓存，或 COPY big.tar . 后又解压删除，压缩包仍滞留在那一层
查被覆盖/删除却未消失的文件
右侧文件树中，Dive 用颜色标记文件状态：
- 绿色：当前层新增的文件（重点关注大文件是否必要）
- 橙色：当前层修改过的文件（说明它来自上层，被复制后改动，双倍空间风险）
- 已删除的文件不会显示，但 Dive 会在“Layer Details”里提示“Files deleted in this layer”，并统计这些删除操作对整体体积无影响——这就是典型“虚胖”信号
聚焦效率评分和浪费空间汇总
右下角的 Image Details 区域会直接给出：
- 镜像总大小
- 未使用文件总大小（例如编译中间产物、文档、调试工具）
- 重复文件总大小（比如同一依赖被不同层多次安装）
- 效率评分（百分比），低于 80% 就值得深入优化
点击“Wasted space”旁边的数字，可跳转到具体哪些文件被判定为冗余，直接定位到路径和大小。
对比层间变化，确认构建逻辑漏洞
按 Ctrl+L 可只看当前层的增删改，按 Ctrl+A 则切换为整个镜像最终文件系统视图。来回切换，就能发现：
- 某个大文件在第3层加入，第5层被
RUN rm -f删除，但它仍计入镜像体积 - 两层都
COPY node_modules，造成重复 - 基础镜像本身带了大量 man 文档或 locale 数据，而你的应用根本用不到
