容器镜像瘦身实战：多阶段构建加速启动

为什么镜像会膨胀

很多生产镜像动辄 1GB 以上：构建阶段的 npm 缓存、gcc 等编译工具链、测试用的 fixture 数据，全都被 COPY 进了最终镜像。镜像大带来三个直接代价：节点拉取慢、冷启动慢、攻击面大。一次实测里，Node.js 应用镜像从 1.24GB 优化到 38MB 后，Kubernetes Pod 从调度到 Ready 的时间从 47 秒降到 11 秒。

第一招：多阶段构建，把工具链留在构建层

核心思路是 构建和运行分离：第一阶段用完整镜像编译打包，第二阶段只拿产物。用一个 AS builder 阶段跑 npm ci 与构建，用 distroless 或 alpine 做最终基镜像。这样一来 node_modules 的编译缓存、.git 目录、devDependencies 全部留在 builder 层，不会进入生产镜像。一个 Spring Boot 项目改用多阶段构建后，镜像从 890MB 降到 210MB，体积只有原来的四分之一。

第二招：.dockerignore，别把仓库全量 COPY 进去

.dockerignore 经常被忽视，但它直接决定了 构建上下文 的大小。上下文越大，每次构建传给 daemon 的数据越多，CI 越慢。至少忽略 node_modules、.git、测试目录和本地日志。配合 COPY 的粒度 优化：先 COPY package.json 再 RUN npm ci，最后再 COPY 业务代码，这样代码变更时依赖层仍能命中缓存，二次构建能快一个数量级。

第三招：层合并与缓存策略

Dockerfile 里每个 RUN 都是一层，层数多会让 联合文件系统 的元数据开销变大。把 apt-get update 与 install 写在同一 RUN，并清掉 /var/lib/apt/lists。更重要的是 指令顺序：变化频率低的（装依赖）放前面，变化频率高的（COPY 业务代码）放后面，最大化缓存命中率。

第四招：换小基镜像，删掉 shell

生产运行不需要包管理器和 shell。Google 的 distroless 基镜像只含运行时，curl、sh 全部砍掉，既省体积又缩小攻击面。对于 Go/Rust 这类静态编译语言，甚至可以用 scratch。Node.js 则可以用 node:22-alpine 再精简一版。实测把 node:22 全量镜像换成精简基镜像，直接省掉约 800MB。

实测对比与建议

把四招组合后，一个典型 Node 应用：镜像体积 1.24GB → 38MB，冷启动 47s → 11s，漏洞扫描高危项从 23 个降到 2 个。建议的落地顺序是：先加 .dockerignore（零风险）→ 上多阶段构建（改 Dockerfile 一次）→ 换 distroless 基镜像（需回归测试）。镜像瘦身不是玄学，而是每次构建都自动生效的 复利工程。