多阶段构建通过统一脚本协调各服务独立的多阶段dockerfile，实现构建逻辑复用、上下文隔离与按需触发；每个服务自含builder和final阶段，脚本动态调用并生成带版本标签的镜像。
多阶段构建在统一构建脚本中管理多个服务，核心是复用构建逻辑、隔离服务上下文、按需触发阶段，而不是把所有服务硬编码进一个Dockerfile。它不是“一个Dockerfile管所有服务”，而是通过脚本协调多个独立但结构一致的Dockerfile，让每个服务自主完成自己的多阶段构建，再由脚本统一调度。
按服务目录分别定义多阶段Dockerfile
每个微服务（如 user-service、order-service）应有自己独立的 Dockerfile，且都采用多阶段构建模式： - 第一阶段（builder）：安装编译工具、拉依赖、构建产物（如 Go 二进制、Node.js dist、Java jar） - 第二阶段（final）：仅复制构建产物，使用最小运行时镜像（如 alpine、distroless） 这样保证各服务镜像体积小、安全基线一致，也避免交叉污染。示例：user-service/Dockerfile
FROM golang:1.21 AS builder WORKDIR /app COPY go.mod ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -o /usr/local/bin/user-api ./cmd/api <p>FROM alpine:3.20 RUN apk add --no-cache ca-certificates COPY --from=builder /usr/local/bin/user-api /usr/local/bin/user-api EXPOSE 8080 CMD ["user-api"]</p>
构建脚本按服务名参数化执行
统一构建脚本（如 build-all.sh）不写死服务逻辑，而是遍历服务目录或接收服务列表，动态调用各自Dockerfile：- 支持指定单个服务构建：
./build-all.sh user-service - 支持批量构建：
./build-all.sh user-service order-service payment-service - 自动识别服务根目录下的 Dockerfile 和 .dockerignore
- 为每个服务生成带版本前缀的镜像标签，如
user-service:v1.2.0
关键逻辑片段：
for service in "$@"; do
if [ -d "$service" ] && [ -f "$service/Dockerfile" ]; then
echo "→ 构建 $service..."
docker build -t "$service:$VERSION" -f "$service/Dockerfile" "$service"
else
echo "⚠️ 跳过 $service：目录不存在或无Dockerfile"
fi
done
利用构建缓存与阶段别名提升效率
多阶段构建天然支持缓存复用，但跨服务时需注意： - 同一基础镜像（如 golang:1.21）的 builder 阶段可被多个服务共享缓存 - 可为 builder 阶段显式命名（AS shared-builder），并在不同服务中复用相同阶段名，增强缓存命中率
- 若某服务需定制构建环境（如加私有依赖源），仍可在其 Dockerfile 内覆盖，不影响其他服务
与CI/CD流水线自然衔接
统一构建脚本可直接嵌入 Jenkins Pipeline 或 Azure DevOps YAML 中： - 在“Build”阶段并行执行多个服务构建：parallel { stage('User') { sh './build-all.sh user-service' } ... }
- 构建完成后，脚本可输出统一清单（JSON格式），供后续推送、部署或镜像扫描环节消费
- 支持传入环境变量控制行为，如 BUILD_ENV=prod 触发 final 阶段优化，SKIP_TESTS=true 跳过测试阶段（若Dockerfile内含测试步骤）
不复杂但容易忽略
