深入Docker镜像层探索器和大小优化器

镜像膨胀的根因：层与层互相覆盖

构建镜像时，Dockerfile 的每条指令都会生成一个新层。当你在 RUN apt-get install 之后删掉缓存，或在后续版本覆盖了前一版本写入的文件时，旧数据并不会消失——它仍留在下层里继续占着磁盘空间。这类「被掩盖的冗余」在镜像变大后很难靠肉眼排查：docker history 只给出每层体积数字，却说不清这一层新增了什么、改了什么、又让哪些下层文件失效。

它如何工作

这个技能的核心是围绕 dive 这一 CLI 工具组织的，把「逐层检查镜像内容」变成一套可重复的流程：

• 逐层展开文件树：针对指定的镜像标签、ID 或 digest，展示每一层相对上一层新增、修改和删除的文件，让你看到体积数字背后的具体内容。
• 量化浪费空间：估算每个层中被后续层覆盖、实际上永远用不到的文件所占空间，定位真正的优化目标。
• 分析文件系统变化：把层与层之间的文件变化对齐呈现，而不是孤立看某个目录，适合排查「为什么这个 500MB 目录还在」这类问题。
• 可接入 CI 校验：能在流水线中以非交互模式运行，跳过 UI 直接输出结果，用来阻止镜像体积的无意义增长。

使用时只需提供一个镜像引用，即可在终端里得到一份按层组织的内容报告。

适用边界与注意点

• 它分析的是层的内容差异，不是运行时行为。删掉多余文件能让镜像变小，但容器启动慢、依赖臃肿这类运行时问题不在此范围内。
• 体积估算基于文件层的覆盖关系，COPY 同名文件替换、层是否被 squash 都会影响结论，看到数字后需结合 Dockerfile 确认。
• 对使用多阶段构建的镜像，它展示的是最终镜像的层内容，不会告诉你中间阶段丢弃了什么——而那通常才是最省空间的部分。
• 面向的是 Docker/OCI 镜像构建产物侧的优化，无法替代基础镜像选型（如改用 alpine 或 distroless）这类决策。