dive 默认显示合并后视图，需加--no-collapsed并按Ctrl+L切Layer Diff才能看清每层增删改；alpine/slim选型取决于依赖链兼容性；RUN应合并安装与清理以保缓存；--squash不能替代多阶段构建。
用 dive 查看镜像层内容时，为什么看不到文件变动？
因为 dive 默认只显示「最终合并后的文件系统视图」，不是每层的增量变更。想看清哪一层加了什么、删了什么，得手动开启分析模式。
- 启动时加
--no-collapsed参数：dive --no-collapsed nginx:alpine - 进入界面后按
Ctrl+L切换到「Layer Diff」视图，才能看到每层新增/修改/删除的文件路径 - 常见误操作：直接在默认视图里翻文件列表，误以为某层“包含”某个大文件——其实它可能被下层
rm -rf删除了，只是没在默认视图中标灰
FROM 基础镜像选 alpine 还是 slim？关键看依赖链
不是越小越好，得看构建阶段是否引入编译工具或运行时依赖。比如 Go 编译产物静态链接，alpine 没问题；但 Python 项目用了 C 扩展（如 psycopg2），alpine 的 musl libc 可能不兼容，强行用反而要装更多补丁包。
- 查清依赖真实调用链：
ldd your-binary或objdump -p your-binary | grep NEEDED -
debian:slim含 glibc + apt，适合大多数 Python/Node.js 生态；alpine:latest更小但需确认所有二进制兼容 - 注意
slim镜像仍含apt和基础工具，构建完不清理会残留大量缓存文件
Dockerfile 中 RUN 合并与分层的取舍
合并 RUN 命令能减少层数，但可能破坏缓存复用或引入不可见副作用。比如把安装依赖和清理缓存写在同一行，会导致只要源码变，整个安装步骤全重跑。
- 推荐写法：
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* - 禁止写法：
RUN apt-get update && apt-get install -y curl+ 单独RUN rm -rf /var/lib/apt/lists/*（第二层无法复用第一层缓存） - 更隐蔽的问题：某些命令（如
pip install）会在/root/.cache留临时文件，即使没显式rm，也建议用--no-cache-dir参数抑制
用 docker buildx build --squash 能否替代多阶段构建？
不能。--squash 只是把最终镜像压成单层，构建中间过程的文件（包括编译器、测试工具、调试符号）依然存在于镜像历史中，导出后再导入仍可能恢复出敏感内容。
- 真正安全瘦身必须用多阶段构建：
builder阶段装 gcc、make，final阶段只COPY --from=builder /app/binary /app/ -
--squash对体积压缩效果有限，且部分 registry（如 ECR）不支持接收 squashed 镜像 - 验证是否真瘦身：用
dive对比 squash 前后各层文件数，重点看/usr/lib/debug、/usr/src是否还残留
镜像瘦身最麻烦的从来不是命令怎么写，而是搞清「哪些文件是运行时必需的」——比如某个动态库看似没被 ldd 列出，但程序用 dlopen 加载，漏删就段错误。这类隐式依赖，只能靠最小化运行测试暴露。
