在 Docker 中，多阶段构建（Multi-stage Builds）是 Docker 17.05 及之后版本引入的一项极其重要的特性。它允许你在一个 Dockerfile 中使用多个 FROM 指令，每个 FROM 指令都代表一个新的构建阶段。

简单来说，它允许你在前面的阶段进行编译、打包等繁重的工作，而在最后一个阶段只将运行所需的最少文件复制过来，生成最终的镜像。

下面我们详细拆解它是如何优化镜像体积和保护源代码安全的。

一、 传统构建 vs 多阶段构建

为了直观理解，我们以一个 Go 语言（或 Java/Node.js）应用为例：

1. 传统做法（单阶段构建）

在没有多阶段构建时，为了编译代码，我们需要一个安装了完整编译器和开发工具的镜像：

# 传统 Dockerfile
FROM golang:1.20

WORKDIR /app
COPY . .

# 编译生成二进制文件
RUN go build -o myapp .

# 运行
CMD ["./myapp"]

• 问题：最终的镜像中不仅包含运行程序 myapp，还包含了 Go 编译器、Go SDK、源代码、缓存文件等。镜像体积通常高达 800MB+。

2. 多阶段构建做法

使用多阶段构建，我们可以将“编译”和“运行”分离开：

# === 阶段 1: 编译阶段 (命名为 builder) ===
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o myapp .

# === 阶段 2: 运行阶段 (最终镜像) ===
FROM alpine:latest
WORKDIR /root/
# 从 builder 阶段复制编译好的二进制文件
COPY --from=builder /app/myapp .

CMD ["./myapp"]

• 结果：最终镜像基于极简的 alpine（仅 5MB 左右），里面只包含一个 myapp 二进制文件。镜像体积骤降至 15MB 左右。

二、 它如何优化镜像体积？

多阶段构建是优化 Docker 镜像体积的“终极武器”，原因如下：

1. 丢弃无用的构建依赖（Build-time Dependencies）：

   • 在编译阶段，我们需要：JDK、Maven、Go SDK、Python-dev、GCC、Git 等。
   • 在运行阶段，我们只需要：JRE、Node 运行时，甚至只需要一个纯净的 Linux 系统（如 Alpine 或 Scratch）。
   • 多阶段构建允许你只把编译好的产物（如 .jar 包、可执行文件、前端 dist 静态目录）复制到最终镜像中，所有的构建工具和中间缓存都会被丢弃。

2. 减少 Docker 镜像层数（Layers）：

   • Docker 镜像是分层存储的，每一条 RUN、COPY 指令都会增加镜像层并占用空间（即使你在下一条指令中删除了文件，空间也不会释放）。
   • 多阶段构建中，前几个阶段的层完全不会写入最终的镜像，只有最后一个 FROM 之后的指令才会决定最终镜像的大小。

三、 它如何保护源代码安全？

在企业级应用中，源代码是核心资产，绝对不能泄露。多阶段构建通过物理隔离保障了源码安全：

1. 源码不残留于最终镜像中：

   • 在传统构建中，即使你在 Dockerfile 结尾写了 RUN rm -rf /src，源码依然存在于镜像的历史层（Layers）中，懂行的人可以通过 docker history 或工具（如 dive）轻松提取出来。
   • 在多阶段构建中，源码只存在于第一阶段（builder）。最终镜像（第二阶段）从来没有导入过源码，只拿到了编译后的二进制文件或混淆后的代码。

2. 防止密钥泄露：

   • 在构建过程中，你可能需要拉取私有 Git 仓库（需要 SSH Key）或下载私有依赖包（需要 Token）。
   • 如果使用多阶段构建，这些敏感的凭证、密钥只在第一阶段使用，绝对不会泄露到分发给客户或部署到生产环境的最终镜像中。

3. 降低安全漏洞（CVE）暴露面：

   • 镜像体积越小，包含的软件包越少，被黑客攻击的漏洞暴露面（Attack Surface）就越小。
   • 例如，最终镜像使用 distroless（一种不带 shell 的超安全镜像）或 alpine，黑客即使攻破了你的应用，也无法在容器内运行 bash、curl 或 apt-get 来进一步渗透。

总结

一句话总结：多阶段构建让 Docker 实现了“构建时重如泰山（工具齐全），运行时轻如鸿毛（安全纯净）”的完美状态。