一、为什么需要多阶段构建
在开发过程中，我们经常会遇到这样的困扰：构建出来的镜像体积太大，不仅占用存储空间，还会影响部署效率。想象一下，你打包了一个简单的Go应用，结果镜像竟然有1GB大小，这就像用集装箱运送一个小包裹，实在太浪费了。
传统构建方式会把编译工具、源代码、临时文件等都打包进最终镜像，而这些在生产环境中根本用不到。这就好比装修房子时把所有工具和材料都留在房间里，既不美观也不实用。
多阶段构建就像装修队的分工合作：第一阶段负责"施工"（编译构建），第二阶段负责"精装"（运行应用），中间只传递必要的成果物。这样得到的镜像既干净又小巧，特别适合生产环境。
二、Docker多阶段构建基础
让我们通过一个Go语言示例来理解基本原理。假设我们有一个简单的HTTP服务：
// main.go
package main
import (
"fmt"
"net/http"
)
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello from multi-stage build!")
}
func main() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8080", nil)
}
传统构建的Dockerfile可能是这样的：
FROM golang:1.20
WORKDIR /app
COPY . .
RUN go build -o server .
CMD ["./server"]
这样构建的镜像会包含整个Go工具链，体积约800MB。而使用多阶段构建：
# 第一阶段：构建阶段
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o server .
# 第二阶段：运行阶段
FROM alpine:3.18
WORKDIR /app
COPY --from=builder /app/server .
CMD ["./server"]
最终镜像基于轻量级的Alpine，只包含编译好的二进制文件，体积不到10MB！两个关键点：
AS builder定义构建阶段别名COPY --from从指定阶段复制文件
三、高级技巧与实战示例
3.1 多阶段构建优化Node.js应用
对于前端项目，我们经常需要处理node_modules的臃肿问题。看这个React项目示例：
# 第一阶段：安装依赖
FROM node:18 AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci
# 第二阶段：构建应用
FROM node:18 AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
# 第三阶段：运行环境
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html
EXPOSE 80
这样处理有三个明显优势：
- 依赖安装层独立，充分利用缓存
- 构建工具不会进入最终镜像
- 静态文件由Nginx高效服务
3.2 处理复杂依赖的Java项目
Maven项目经常需要下载大量依赖，这个示例展示了如何优化：
# 第一阶段：解决依赖
FROM maven:3.8-openjdk-11 AS deps
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
# 第二阶段：构建应用
FROM deps AS builder
COPY src ./src
RUN mvn package
# 第三阶段：运行环境
FROM openjdk:11-jre-slim
COPY --from=builder /app/target/*.jar /app.jar
CMD ["java", "-jar", "/app.jar"]
特别提醒：
go-offline会下载所有依赖- 分离pom.xml复制可以利用缓存
- 最终使用jre而不是jdk
四、常见问题与解决方案
4.1 构建缓存失效问题
有时候小小的改动会导致整个缓存失效。比如这个Python项目：
FROM python:3.9 AS builder
# 先复制requirements.txt可以更好利用缓存
COPY requirements.txt .
RUN pip install -r requirements.txt
# 然后再复制其他文件
COPY . .
经验法则：
- 把变化频率低的指令放前面
- 分步骤复制文件
- 合理使用.dockerignore
4.2 构建参数传递
跨阶段传递构建参数很有用：
# 第一阶段
FROM golang AS builder
ARG VERSION=1.0.0
RUN go build -ldflags="-X main.version=$VERSION" -o app .
# 第二阶段
FROM alpine
COPY --from=builder /go/app .
构建时传入参数：
docker build --build-arg VERSION=2.0.0 -t myapp .
五、安全与最佳实践
- 永远不要使用latest标签
- 最小化基础镜像（推荐distroless）
- 定期扫描镜像漏洞
- 使用非root用户运行
例如这个安全加固的示例：
FROM golang AS builder
# ...构建步骤...
FROM gcr.io/distroless/base
COPY --from=builder /app/server /app/
USER nobody
CMD ["/app/server"]
六、性能对比与选择建议
通过实际测试对比不同方案的镜像大小：
| 构建方式 | Go示例大小 | Node示例大小 | Java示例大小 |
|---|---|---|---|
| 传统构建 | 800MB | 1.2GB | 650MB |
| 多阶段构建 | 10MB | 120MB | 150MB |
| 极致优化构建 | 6MB | 25MB | 45MB |
选择建议：
- 开发环境可以使用传统构建方便调试
- CI/CD流水线强烈推荐多阶段构建
- 对安全要求高的考虑distroless
七、总结与展望
多阶段构建就像精炼原油的过程，去粗取精，只保留最有价值的部分。它不仅减小了镜像体积，还提高了安全性，是现代容器化部署不可或缺的技术。
未来随着Wasm等新技术的发展，可能会出现更极致的构建方案。但多阶段构建的核心思想——分离构建环境和运行环境——将会长期适用。
记住：好的镜像应该像瑞士军刀，不是把所有工具都带上，而是精心选择最合适的组件。
评论