在现代云原生应用开发中，容器化部署已经成为标准流程。然而，许多团队在构建容器镜像时，往往将编译环境与运行环境混为一谈，导致最终生成的镜像体积庞大且存在潜在的安全风险。多阶段构建技术通过在单个Dockerfile中定义多个阶段，巧妙地解决了这一问题，使得构建产物能够以最精简的形式在目标环境中运行。
为什么需要分离构建与运行环境？
在传统的单阶段构建模式中，我们通常在一个基础镜像中安装所有的依赖包、编译工具链以及运行时环境。以Java项目为例，为了编译源码，我们需要引入JDK、Maven或Gradle等工具；但在应用实际运行时，仅仅需要JRE即可。如果将编译工具保留在最终镜像中，不仅会使镜像体积膨胀几倍甚至十几倍，还会显著增加容器拉取和启动的时间。
更为严重的是安全隐患。编译工具链中往往包含各种系统级命令（如curl、wget、gcc等），这些工具一旦被恶意攻击者利用，就可以轻松在容器内部进行提权或横向移动。通过分离构建与运行环境，我们可以确保最终镜像中只包含执行业务逻辑所必需的二进制文件和库，极大程度地缩小了攻击面。
多阶段构建的核心思想在于职责分离。它允许我们在第一个阶段使用功能完整的构建镜像来编译代码、运行测试并生成制品；然后在第二个阶段使用极简的运行镜像，仅将上一阶段生成的制品复制过来。这种机制不仅让Dockerfile的维护更加清晰，也完美契合了Docker镜像分层存储的设计理念。
如何编写多阶段构建的Dockerfile？
多阶段构建的语法非常直观，主要通过多次使用FROM指令来实现。我们可以为每个FROM指令指定一个别名（使用AS关键字），然后在后续阶段通过COPY --from指令来引用前序阶段的产物。这种方式打破了传统构建中上下文传递的限制，让跨阶段的数据流动变得安全可控。
下面以一个Go语言项目为例，展示如何将编译过程与运行过程彻底解耦。Go语言天生具备静态编译的优势，非常适合用来演示多阶段构建的威力。我们将第一阶段命名为builder，用于拉取依赖和编译二进制文件；第二阶段则使用极简的alpine镜像来运行该文件。
# 第一阶段：构建阶段 FROM golang:1.19 AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . # 执行静态编译，不依赖C库 RUN CGO_ENABLED=0 GOOS=linux go build -o myapp . # 第二阶段：运行阶段 FROM alpine:latest WORKDIR /app # 从builder阶段拷贝编译好的二进制文件 COPY --from=builder /app/myapp . # 运行应用 CMD ["./myapp"]
在上述示例中，COPY --from=builder /app/myapp . 是连接两个阶段的关键纽带。需要注意的是，使用COPY指令时，源路径必须是构建阶段中真实存在的文件路径。此外，如果我们在构建过程中使用了某些缓存目录（如npm的缓存或Go的模块缓存），这些缓存仅存在于构建阶段，不会污染最终的运行镜像，这也是多阶段构建带来的隐性优势之一。
多阶段构建的进阶优化技巧
掌握了基本语法后，我们还可以通过一些进阶技巧进一步压缩镜像体积并提升构建效率。首先是基础镜像的选择，对于运行阶段，除了常用的alpine之外，还可以考虑使用scratch。scratch是一个特殊的空镜像，它不包含任何文件系统。如果我们的应用是像Go这样完全静态编译的程序，直接使用scratch作为基础镜像可以将最终体积缩小到几兆字节。
其次，合理利用构建缓存能够大幅缩短构建时间。在多阶段构建中，我们应该将不常变动的步骤放在前面。例如，先拷贝依赖管理文件（如package.json或go.mod）并执行依赖安装，然后再拷贝业务源码。这样在代码变更时，Docker会直接复用之前缓存的依赖层，避免了重复下载依赖包的时间消耗。
最后，在处理包含敏感信息的构建阶段时，我们需要格外小心。例如，在编译阶段可能需要访问私有的代码仓库或依赖注册表，这通常需要提供SSH密钥或NPM Token。这些敏感信息绝对不能留在最终镜像中。通过多阶段构建，我们可以安全地在第一阶段使用这些密钥，而在第二阶段由于只复制了编译产物，密钥自然被隔离在了构建环境之外，从而保障了系统的安全性。
Docker多阶段构建镜像优化构建环境修改时间：2026-08-21 20:14:59