dive 是最直观的 docker 镜像分层分析工具，可逐层查看文件归属与变更，左侧列构建顺序各层，右侧显示叠加后文件系统并高亮 added/modified/deleted 文件，重点关注 modified 及跨层重复大文件以识别层间耦合与清理缺陷。
分析 docker 镜像各层的依赖关系和耦合度，核心是理解“哪些文件来自哪一层”“哪些层之间存在隐式依赖”，以及“某层修改是否必然触发下层重建”。这不是靠肉眼猜，而是结合工具输出+构建逻辑推演。
用 dive 工具逐层查看文件归属与变更
Dive 是目前最直观的分层分析工具。它左侧列出所有层（按构建顺序从底向上），右侧显示当前层及之前所有层叠加后的完整文件系统视图，并高亮标出：
- Added：该层新增的文件（如 RUN pip install 产生的 .pyc 或 site-packages）
- Modified：该层修改了前一层已存在的文件（比如 COPY 覆盖了旧配置）
- Deleted：该层删除了前一层的文件（如 RUN apt-get clean && rm -rf /var/lib/apt/lists/*）
重点关注 Modified 和跨层重复出现的大文件（如某个 .so 库在多层中被反复复制或移动）——这往往意味着层间耦合过紧，或清理不彻底，直接拉低镜像效率得分。
通过 docker history 定位每层的构建指令与大小
运行 docker history <image></image> 可看到每层对应的 Dockerfile 指令、创建时间、大小（SIZE 列）。关键观察点：
- 某层 SIZE 异常大（如 >50MB），但指令只是 COPY 或 RUN 简单命令 → 很可能前序层残留了未清理的缓存（如 apt-get 下载包、npm_modules）
- 相邻两层都含 RUN 指令，且第二层明显依赖第一层安装的工具（如先 RUN apt-get install curl，再 RUN curl -sS https://... | bash）→ 存在强顺序依赖，不可随意调换或合并
- 某层 SIZE 为 0B，但 CREATED BY 显示非空指令（如 EXPOSE、LABEL）→ 该层无文件变更，仅元数据，基本无耦合风险
识别隐式依赖：看文件路径与生命周期是否错位
耦合度高的典型信号不是语法错误，而是构建逻辑错位：
- 源码与依赖混在同一层：例如 COPY . . && RUN pip install -r requirements.txt → 代码一改，整个依赖层失效，无法利用缓存
- 临时文件未清理就进入下一层：RUN apt-get update && apt-get install -y xxx 后没加 apt-get clean，导致 /var/lib/apt/lists/ 占用几十 MB 并固化进该层
- 配置文件被多次覆盖：COPY config1.yml /app/ → RUN generate-config.sh → COPY config2.yml /app/ → 中间生成的配置实际被最后一步覆盖，但前两层体积仍保留
这类问题不会报错，但会让层与层之间产生“假依赖”——表面看是独立层，实则因路径冲突或状态残留被迫绑定。
多阶段构建中依赖解耦的验证方法
若使用多阶段构建（如 builder + runtime），需单独检查每个 stage 的输出层：
- 运行
docker build --target builder -t myapp-builder .，再用 dive 分析 builder 镜像 → 确认依赖是否真正隔离在 builder 阶段 - 检查 final 阶段的 COPY --from=builder 是否只复制必要产物（如单个 jar 或 dist/ 目录），而非整个 /app
- 对比两个 stage 的相同基础镜像层哈希值（docker history 输出的 IMAGE 列）→ 若一致，说明基础环境被复用，耦合度低
