容器镜像瘦身的几个实际收益点

先看清镜像里到底装了什么

很多镜像并不是业务代码大，而是构建工具、包管理器缓存和调试依赖一层层叠上去的。先用 docker history 看每层大小，再用 dive 检查被后续层删除却仍留在前层的文件。曾经一个 1.2 GB 的 Java 镜像，真正运行所需的 jar 只有 90 MB，其余都是 Maven 仓库、JDK 源码包和临时下载文件。把哪一层贡献了多少体积列成表，优化才有目标，而不是盲目换基础镜像。

基础镜像要按运行时而选

运行 Java 服务不必带完整 JDK，构建阶段用 JDK，运行阶段换 JRE 或 jlink 裁剪后的运行时；Go 和 Rust 可以直接用 scratch 或 distroless，只留二进制和证书。换镜像前先确认 glibc、时区、CA 证书和字体依赖，否则会出现本地能跑、容器里 DNS 解析失败的问题。我们通常保留一个带 shell 的 debug 变体，生产镜像则尽量不带包管理器。

多阶段构建把工具留在构建阶段

把编译、测试、打包放在 builder 阶段，最终阶段只 COPY 产物。这样 Maven、npm、gcc 都不会进入运行镜像，层数也更容易控制。注意 COPY --from 只复制必要目录，不要把整个 target 或 node_modules 搬过去；前端项目可以在 builder 里完成构建，运行阶段只留静态文件和轻量服务器。

清理缓存要放在同一层

apt-get install 之后立刻执行 rm -rf /var/lib/apt/lists/*，并且和安装写在同一条 RUN 里，否则删除动作只发生在下一层，前一层体积仍然存在。pip 用 --no-cache-dir，npm 用 npm ci --omit=dev，同时用 .dockerignore 排除 .git、测试数据和本地日志，避免把无关文件送进构建上下文。

收益要落到发布流程

镜像从 1.2 GB 降到 180 MB 后，最直接的变化是冷启动拉取从几分钟降到十几秒，弹性扩容和回滚都更快；仓库存储和跨区传输费用同步下降，CVE 扫描的组件数量也少了一个量级。建议把镜像大小、层数和高危漏洞数做成发布门禁，超过阈值就告警，避免几个月后又慢慢膨胀回去。