Docker 多阶段构建与镜像体积压缩：从几 GB 到几百 MB 的实战路径

一、镜像体积不是一个 aesthetic 问题，而是部署速度、存储成本和攻击面的综合问题

一个 2GB 的 Docker 镜像和一个 200MB 的 Docker 镜像，在本地开发时感受不到太大差别——反正只需要拉一次。但在生产环境，镜像是每次部署都要传输的文件：CI/CD 管道需要构建它，镜像仓库需要存储它，服务器需要拉取它，扩容时需要用它创建新容器。镜像体积每大 100MB，部署时间就多几秒；每天部署十次，一年就是几百分钟的等待时间。更重要的是，镜像体积越大，包含的不必要文件和潜在漏洞就越多，攻击面就越大。

Docker 多阶段构建（multi-stage build）是解决镜像体积问题的核心手段。它的思路很简单：在一个Dockerfile里定义多个构建阶段，每个阶段可以基于不同的基础镜像，只有最后一个阶段的内容会出现在最终镜像里。这样，你可以把编译工具、依赖管理工具和中间产物都放在前面的构建阶段，只把编译后的二进制文件或打包后的静态文件复制到最终阶段。

但多阶段构建不是「写了就一定能减小体积」的魔法。如果你的最终阶段仍然基于臃肿的基础镜像（比如node:latest而不是node:alpine），或者你没有正确清理包管理器的缓存，镜像体积仍然会很大。镜像体积压缩是一场在每个细节上抠出几十 MB 的持久战。

二、多阶段构建的典型模式：以 Node.js 应用为例

flowchart TD A[源代码] --> B[阶段1: 依赖安装] B --> C[阶段2: 构建] C --> D[阶段3: 生产运行] D --> E[最终镜像] B -.->|只复制 package*.json| B C -.->|复制源码 + node_modules| C D -.->|只复制构建产物| D E --> F[体积小/只含运行时依赖]

下面是一个典型的 Node.js 应用的多阶段Dockerfile，它把依赖安装、构建和运行时拆成了三个阶段：

# 阶段1：安装依赖 FROM node:20-alpine AS deps WORKDIR /app COPY package*.json ./ RUN npm ci --only=production && npm cache clean --force # 阶段2：构建（如果需要 TypeScript 编译、打包等） FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # 阶段3：生产运行 FROM node:20-alpine AS runner WORKDIR /app ENV NODE_ENV=production # 从 deps 阶段复制生产依赖 COPY --from=deps /app/node_modules ./node_modules # 从 builder 阶段复制构建产物 COPY --from=builder /app/dist ./dist COPY --from=builder /app/package*.json ./ EXPOSE 3000 CMD ["node", "dist/server.js"]

这个Dockerfile的最终镜像里，不包含devDependencies、不包含源代码（只含构建后的dist）、不包含构建工具。对比把所有东西都放在一个阶段的写法，体积通常能减少 60%-80%。

但这里有一个细节：.dockerignore文件。如果.dockerignore没有正确配置，COPY . .会把node_modules、dist、.git等文件都复制进去，导致构建缓存失效和镜像体积膨胀。一个合理的.dockerignore应该排除node_modules、构建产物、测试覆盖报告和 Git 目录。

三、基础镜像选择：Alpine、Distroless 与 Scratch 的权衡

基础镜像的选择，是决定最终镜像体积的上限。以下是几种常见选择的对比：

• node:20（基于 Debian）：约 1GB，包含完整的包管理器和大量系统工具，适合调试，不适合生产。
• node:20-alpine（基于 Alpine Linux）：约 180MB，体积小，包含包管理器，适合大多数生产场景。
• node:20-alpine+ 多阶段构建 + 只复制必要文件：最终镜像通常 200-300MB。
• Google 的 Distroless：约 50MB，只包含应用和运行时依赖，没有包管理器，没有 shell，安全性高，但调试困难。
• scratch：空镜像，适合完全静态链接的 Go 或 Rust 二进制文件，镜像体积可以小到几 MB。

对于大多数独立开发者的项目，Alpine是基础镜像的甜点区：体积小、调试方便、生态完整。只有在镜像体积极端敏感的场景（如 serverless 函数、边缘计算），才需要考虑Distroless或scratch。

但 Alpine 也有自己的坑：它的 C 标准库是musl，而不是大多数 Linux 发行版用的glibc。某些原生模块（如Sharp、node-sass、或使用nan的旧模块）在 Alpine 下可能需要重新编译，或者干脆不兼容。在切换到 Alpine 之前，务必在本地用 Alpine 基础镜像完整跑通构建和运行。

四、进阶压缩技巧：层合并、.dockerignore 与镜像扫描

除了多阶段构建和基础镜像选择，还有几个进阶技巧可以进一步压缩镜像体积。

首先是层合并。Docker 的每一行RUN、COPY、ADD都会产生一个新层，每层都会占用空间。如果一行RUN安装了包但下一行没有清理缓存，缓存就会留在镜像里。正确的写法是把安装和清理放在同一个RUN指令里：

# 不好的写法：apt 缓存留在了镜像里 RUN apt-get update RUN apt-get install -y curl # 此时 apt 缓存还在镜像里 # 好的写法：安装和清理在同一层 RUN apt-get update && \ apt-get install -y curl && \ rm -rf /var/lib/apt/lists/*

其次是.dockerignore的精细配置。很多人知道要排除node_modules，但容易忽略.git、*.log、coverage、本地配置文件等。一个严格的.dockerignore可以显著减少构建上下文的大小，加快构建速度，也避免敏感文件被意外打包进镜像。

最后是镜像安全扫描。压缩镜像体积的同时，也应该减少镜像里的漏洞。docker scout（Docker 官方）、trivy（开源）、grype（开源）都是不错的工具。它们可以扫描镜像里的系统包和可溶性依赖，报告已知漏洞。在 CI 里集成镜像扫描，可以在部署前发现安全问题，而不是等安全团队找上门。

另一个值得注意的点是「镜像标签的不可变性」。生产环境部署时，应该使用具体的版本标签（如myapp:2024.07.06-abc123），而不是latest。latest标签在拉取时可能指向不同的镜像，导致部署不一致。latest适合开发环境，不适合生产。

五、总结

Docker 镜像体积压缩不是一次性的优化任务，而是一套需要在Dockerfile、基础镜像选择、.dockerignore配置和 CI 流程里持续执行的纪律。多阶段构建把构建时依赖和运行时依赖分离，Alpine 基础镜像在体积和可用性之间取得平衡，层合并和精细的.dockerignore进一步抠出冗余。镜像体积小了，部署快了，攻击面也小了——这是工程上少有的「做了就有明显回报」的优化。