为何Dockerfile需用多FROM指令？单FROM指令为何不可取？

通过将构建环境与运行环境分离，打造高效、安全的最终镜像

• 第一阶段用体积较大的golang镜像完成应用编译
• 第二阶段基于轻量的alpine镜像搭建运行环境
• 用COPY --from=builder指令只把编译好的二进制文件(myapp)复制到最终镜像，Go SDK、源码等编译相关内容全部舍弃

示例Dockerfile #

# Stage 1: Build the application
FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o myapp .

# Stage 2: Create the minimal runtime image
FROM alpine:latest AS final
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]

为什么不先本地编译再用单FROM指令？多阶段构建有啥优势？ #

先本地编译再做单FROM镜像的问题 #

• 环境不统一易出问题：本地的Go版本、系统架构和容器运行环境可能存在差异，比如在Mac上编译的二进制放到Linux容器里跑不起来，或者团队成员用不同Go版本编译导致产物行为不一致，排查成本高。
• 跨平台构建太繁琐：要给ARM等其他架构做镜像时，本地得手动切换编译环境、处理交叉编译配置，而Docker多阶段构建配合buildx工具就能一键完成跨平台镜像构建，不用自己折腾环境。
• 团队协作成本高：每个开发者都得在本地安装对应版本的Go环境，新人入职光搭环境就得花不少时间；多阶段构建把编译过程完全放在Docker容器里，本地只需安装Docker即可，无需配置编译依赖。

多阶段构建的核心优势 #

• 极致压缩镜像体积：最终镜像仅保留运行必需的二进制文件和基础依赖（如示例中的证书），编译阶段的SDK、源码、中间产物全部被丢弃，原本几百MB的镜像可压缩到几MB级别，拉取和启动速度大幅提升。
• 提升镜像安全性：编译环境中的开发工具、多余系统库不会进入最终镜像，减少了攻击面——Go镜像包含大量开发工具，潜在漏洞更多，而轻量的alpine镜像更干净，没有多余可执行文件供攻击者利用。
• 构建流程一体化：从源码到成品镜像的全流程都在Docker中完成，无需先本地编译再复制文件到镜像，CI/CD流水线可直接使用该Dockerfile，流程简洁且不易出错。
• 构建逻辑更灵活：可拆分多个构建阶段，比如先编译前端再编译后端，每个阶段职责单一，还能在阶段间复用构建产物，比单阶段构建更灵活。

内容的提问来源于stack exchange，提问作者J.J. Beam