Docker 镜像层分析器

要解决的问题

镜像构建完成后体积失控，是容器化交付中最常见的返工来源之一。一个 500MB 的镜像，运行时真正用到的可能只是其中一部分；其余空间被构建缓存、工具链、中间产物和重复的基础层占据。这些冗余分散在几十个层里，靠 docker history 逐行翻看很难判断哪一层该合并、哪一层该删，排查成本随层数线性上升。

核心能力与工作方式

这个技能把层分析拆成两个互补的数据源：

• Registry 层信息：通过 Docker Registry HTTP API v2 直接读取镜像的 manifest 与各层 blob，拿到每一层的大小、压缩前后体积以及层间关系。
• 逐层下钻检查：借助 dive CLI 逐层查看新增文件、已在下层存在的文件，以及属于构建过程的临时产物。

在此基础上它会完成三件事：按大小汇总并排序各层，标记可回收的浪费空间，最后给出多阶段构建的优化建议——例如把编译工具和依赖缓存留在构建阶段，只把最终产物复制进运行镜像。

适用边界与注意点

• 所在环境需能访问目标 registry，且本地可用 dive CLI；私有 registry 的鉴权方式会影响拉取。
• 分析结果依赖 manifest 中如实记录的层信息，被 squash 或导出再导入的镜像，层边界可能已合并，原始归属不再可见。
• 多阶段构建建议是方向性的，实际收益取决于具体构建步骤，仍需在真实构建中验证。