多阶段构建是企业生产环境必备实践，可缩小镜像体积60%–85%，仅保留二进制、ca证书和必要配置，显著降低攻击面与漏洞风险。
多阶段构建是企业级容器化转型中降低风险、提升交付质量的关键技术，不是锦上添花的技巧，而是生产环境落地的必备实践。
为什么企业必须用多阶段构建
单阶段构建的镜像在生产环境中会暴露大量攻击面：编译器、源码、调试工具、临时文件、未清理的依赖缓存全被打包进去。某金融客户曾因生产镜像中残留 go build 工具链和未加密的本地配置文件，被扫描工具识别为高危资产。多阶段构建天然实现“构建与运行分离”，让最终镜像只保留二进制、CA证书、必要配置三类内容，体积平均缩小60%–85%，启动更快，漏洞更少。
Go/Java/Node.js 三类主流语言的写法要点
不同语言对多阶段构建的适配逻辑略有差异，核心都围绕“静态产物提取”展开：
- Go：启用 CGO_ENABLED=0 GOOS=linux 编译静态二进制，避免运行时依赖 glibc；第二阶段用 alpine:latest 或 distroless/cc 镜像，不装 shell 也能运行
- Java（Spring Boot）：Maven 构建后生成 fat-jar，第一阶段用 maven:3.9-openjdk-17，第二阶段用 eclipse/jetty:11-jre17-slim 或 openjdk:17-jre-slim，直接 COPY target/*.jar
- Node.js：分三阶段更合理——builder（安装 node_modules + 构建）、test（独立阶段跑单元测试，失败即中断）、runtime（仅复制 dist/ 和 node_modules/ 生产依赖，用 node:18-alpine）
企业落地必须配置的四个加固项
光写对 Dockerfile 不够，还需配套机制保障长期稳定：
- 强制 stage 命名 + --target 检查：所有 FROM 后加 AS builder 等语义化名称；CI 流水线中用 docker build --target runtime ... 显式指定输出阶段，防止误构建中间镜像
- 禁止 COPY . /app 无过滤：改用 .dockerignore 排除 node_modules/, .git, *.md, tests/ 等非运行必需内容
- 基础镜像统一纳管：内部 Registry 中预置 our-registry/base/golang:1.21-builder、our-registry/base/alpine-runtime:3.19 等镜像，带 SBOM 和 CVE 扫描报告，禁止直接拉取公网镜像
- 构建时注入不可变元数据：用 build-arg 注入 BUILD_DATE、VCS_REF、IMAGE_TAG，并在镜像内生成 /run/.buildinfo 文件，供审计与回溯
常见踩坑与绕过方案
真实产线中高频问题集中在构建缓存与跨阶段权限两方面：
- Go mod download 缓存失效：在 builder 阶段开头加 RUN mkdir -p /root/go/pkg/mod && chmod 777 /root/go/pkg/mod，再 COPY go.mod go.sum . 后立即 RUN go mod download，利用 BuildKit 的 layer 缓存加速
- Alpine 中缺少 ca-certificates 导致 HTTPS 请求失败：第二阶段务必执行 RUN apk add --no-cache ca-certificates，不能依赖基础镜像自带（alpine:latest 默认不含）
- 非 root 用户无法读取 COPY --from 的文件：在 builder 阶段末尾加 RUN chmod 755 /app/myapp，或在 runtime 阶段用 COPY --from=builder --chown=appuser:appuser /app/myapp .
- 前端项目 public/ 资源未复制：若用 nginx:alpine 作 runtime，需在第二阶段 COPY --from=builder /app/dist /usr/share/nginx/html，并确认 nginx.conf 已挂载或覆盖
