多阶段构建的核心是分离构建与运行环境：构建阶段使用完整工具链（如maven、golang）编译打包，运行阶段仅用轻量镜像（如alpine、slim）复制产物，通过copy --from精准传递可执行文件及必要资源，彻底剥离编译器、源码、缓存等冗余内容，实现镜像极致瘦身与安全加固。
多阶段构建不是加功能，而是做减法——把编译器、源码、依赖包、缓存这些运行时根本用不着的东西，全留在构建阶段里，最终镜像只留下能跑起来的那几个文件。
明确划分两个关键阶段
一个 Dockerfile 里写两个 FROM，各司其职：
-
构建阶段（Builder）：用带完整工具链的镜像，比如
golang:1.21、maven:3.8或node:18。在这儿装依赖、编译代码、生成二进制或 jar 包。 -
运行阶段（Final）：换轻量基础镜像，比如
alpine:latest（约 5MB）、debian:slim（约 60MB）甚至scratch（0MB，仅适用于静态链接二进制）。只从构建阶段复制最终产物，不带任何构建痕迹。
正确使用 COPY --from 复制产物
这是连接两个阶段的唯一桥梁，必须指定来源阶段名：
- 构建阶段定义为
FROM golang:1.21 AS builder，运行阶段就用COPY --from=builder /app/main . - 路径要写准：源路径是构建阶段里的绝对路径；目标路径是运行阶段的工作目录下位置。
- 别漏掉运行必需的辅助文件，比如配置文件、证书、静态资源，可以一并
COPY --from=builder复制过来。
配合其他优化动作效果更明显
单靠多阶段还不够，顺手加几条能再压几 MB：
- 构建阶段里编译完立刻清理缓存，比如
RUN apt clean && rm -rf /var/lib/apt/lists/*或RUN npm cache clean --force； - Go 应用开启静态编译：
CGO_ENABLED=0 GOOS=linux go build -a -o main .，避免运行时依赖 libc； - Java 应用优先用
eclipse-jetty:jre17-slim或amazoncorretto:17-alpine-jre这类仅含 JRE 的镜像，别用带 JDK 的； - 在项目根目录放好
.dockerignore，排除node_modules、.git、tests等无关内容。
选对基础镜像直接影响最终大小
运行阶段的基础镜像不是越小越好，得看兼容性。常见选择参考：
-
alpine:latest：约 5MB，适合大多数语言，但注意某些 C 扩展可能不兼容； -
debian:slim：约 60MB，glibc 完整，兼容性好，适合 Python/Java 等； -
gcr.io/distroless/static：约 5MB，纯静态运行环境，无 shell，安全性高； -
scratch：0MB，只接受静态二进制，启动命令必须是ENTRYPOINT ["./myapp"]，不能有CMD调用 shell。
