多阶段构建的核心是轻量化，即只保留运行必需内容。构建阶段用完整工具链生成产物后清理临时文件，运行阶段选用最小基础镜像（如distroless或alpine），精准复制产物并精简启动逻辑与JVM参数。
多阶段构建本身不是目的，而是达成轻量化的手段。关键在于“只保留运行必需”，而不是“把所有东西都塞进最终镜像”。只要运行时能正常加载、启动、处理请求，其他一切都可以在构建阶段剥离。
明确分离构建与运行职责
构建阶段（builder）只干一件事：编译、打包、生成可执行产物。它可以用完整工具链（如 maven、golang、node），但它的输出——比如 JAR、二进制、dist 目录——就是唯一需要传递给下一阶段的资产。
- 用 AS builder 命名第一阶段，便于后续引用
- 只 COPY 源码和依赖声明文件（pom.xml / package.json / go.mod），避免把 .git、.idea、测试资源等无关内容带入构建上下文
- 构建完成后立即清理临时文件（如
RUN mvn clean package -DskipTests && rm -rf ~/.m2/repository），减少该阶段层体积
选用最小化运行基础镜像
运行阶段镜像决定最终体积上限。优先顺序是：distroless > alpine > slim > full OS（如 ubuntu、debian）。
- distroless 镜像不含 shell、包管理器、甚至 libc 外的大部分系统工具，仅含运行时依赖（如 JRE 或 glibc），体积常低于 20MB
- Alpine 镜像虽小（约 5MB base），但需注意 musl libc 兼容性；若应用依赖 glibc 特性（如某些 JNI 库），应改用
debian:slim或定制 distroless - Java 场景推荐
eclipse-jdtls:latest或官方amazoncorretto:21-jre-alpine，避免使用openjdk:21-jdk（含 javac、javadoc 等非运行所需组件）
精准复制运行产物，拒绝全量拷贝
第二阶段只 COPY 第一阶段生成的可执行文件或目录，不重复 COPY 源码、配置模板、文档、脚本等。
- 用
COPY --from=builder /app/target/app.jar /app/，而非COPY --from=builder /app /app - 若需配置文件，单独 COPY，并放在标准路径（如
/app/config/），避免混入构建产物目录 - 静态资源（如前端 dist）建议统一归入单一目录后整体 COPY，不逐个文件操作
精简运行时环境与启动逻辑
镜像小了，不代表运行时就轻——还要控制进程自身开销。
- Java 应用启用
-XX:+UseContainerSupport和-XX:MaxRAMPercentage=75.0，让 JVM 正确感知容器内存限制 - 避免在 Dockerfile 中写复杂 shell 启动脚本；用
ENTRYPOINT ["java", "-jar", "app.jar"]这类直接调用方式，减少中间解释层 - 关闭非必要功能：Spring Boot 可设
spring.main.lazy-initialization=true，延迟初始化非核心 Bean
