我的 Spring Boot 镜像从 500MB 瘦到 50MB，老板惊呆了！

开头：一次尴尬的线上事故

还记得上周五下午，公司的新项目要上线。我自信满满地执行了 docker pull，然后…等待了 20 分钟。

老板走过来说：”小王，你怎么还在 pull？其他人都部署完了！”

我一看镜像大小：520MB！而隔壁小张的镜像只有 50MB…当场社死。

痛定思痛，我决定深入研究 Docker 多阶段构建。今天就把我的踩坑和优化经验分享给大家。

问题：为什么镜像这么臃肿？

我当时的 Dockerfile 是这样的（是不是和你写的很像？）：

FROM openjdk:17-jdk-slim
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests
COPY target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

这个镜像包含了很多不应该存在的东西：

• Maven 构建工具：运行时根本用不到
• 源代码：已经编译成 class 文件了
• 整个 JDK：其实只需要 JRE
• 编译过程中的缓存：临时文件一大堆

对比图：

pie title 镜像体积对比
    "运行需要（JRE+jar）" : 48
    "Maven 构建工具" : 200
    "JDK（JRE之外）" : 150
    "源代码+缓存" : 122

就像你搬家，把装修工具、建筑垃圾、图纸全打包带走了，只为了住新家？

核心概念：什么是多阶段构建？

多阶段构建就是：把构建和运行分成两个独立的阶段。

打个比方：

你做饭的时候：

1. 备菜阶段：洗菜、切菜、准备调料（需要厨房、菜板、刀具）
2. 炒菜阶段：起锅烧油、爆炒出锅（只需要锅、铲子）

上菜的时候，你只需要炒好的菜，不需要把厨房、菜板、刀具都端上桌，对吧？

Docker 多阶段构建也是这个道理：

• 构建阶段：使用 Maven、JDK 编译代码
• 运行阶段：只保留 JRE 和打包好的 jar

多阶段构建流程图

graph LR
    subgraph 构建阶段
        A[源代码
pom.xml] --> B[Maven
编译]
        B --> C[目标文件
target/*.jar]
        C --> D[构建产物]
    end
    
    subgraph 运行阶段
        D --> E[JRE
轻量级运行时]
        E --> F[最终镜像
48MB]
    end
    
    style D fill:#f9f,stroke:#333,stroke-width:2px
    style F fill:#9f9,stroke:#333,stroke-width:4px

可以看到：构建阶段产生的只有构建产物，其他都被丢弃了。

实战：从 520MB 到 48MB 的蜕变

步骤 1：改造 Dockerfile

创建新的 Dockerfile（注意看 AS builder 和 --from=builder）：

# ========== 阶段 1：构建 ==========
# 就像备菜阶段，需要所有工具
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build

# 复制 pom.xml（利用 Docker 缓存优化）
COPY pom.xml .

# 复制源代码
COPY src ./src

# 编译（这里会生成 target/*.jar）
RUN mvn clean package -DskipTests

# ========== 阶段 2：运行 ==========
# 就像炒菜阶段，只需要锅和菜
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app

# 只复制构建好的 jar 文件（注意 --from=builder）
COPY --from=builder /build/target/*.jar app.jar

# 创建非 root 用户（安全最佳实践）
RUN addgroup -S spring && adduser -S spring -G spring
USER spring:spring

EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

步骤 2：构建镜像

docker build -t myapp:v2.0 .

注意观察输出，你会看到两个 FROM，分别代表两个阶段。

步骤 3：对比镜像大小

docker images | grep myapp

你可能会看到这样的结果：

减少了 90.8%！老板看完直接给我涨工资了（开玩笑的）。

可视化对比

gantt
    title 镜像拉取时间对比
    dateFormat  HH:mm:ss
    axisFormat  %H:%M
    
    section 优化前（520MB）
    下载镜像    :crit, 2023-01-01 08:00, 20m
    
    section 优化后（48MB）
    下载镜像    :2023-01-01 08:25, 2m

时间对比：

• 优化前：20 分钟（520MB）
• 优化后：2 分钟（48MB）
• 提升：10 倍速度

深入解析：5 个关键技巧

1. 阶段命名（AS）

FROM maven:3.9-eclipse-temurin-17 AS builder

AS builder 给这个阶段起了个名字，方便后面引用。就像给备菜阶段贴个标签”这是 builder 阶段”。

2. 选择性复制（–from）

COPY --from=builder /build/target/*.jar app.jar

这句是核心魔法！它只从 builder 阶段复制编译好的 jar 文件，其他东西统统不要。

就像你只把菜端上桌，厨房、菜板、刀具都留在厨房里。

3. 基础镜像选择

• 构建阶段：用 maven:3.9-eclipse-temurin-17，包含 Maven 和 JDK，适合编译
• 运行阶段：用 eclipse-temurin:17-jre-alpine，只包含 JRE，体积小 10 倍

Alpine 是超精简的 Linux 发行版，只有 5MB 左右（普通发行版 100MB+）。

4. 非 root 用户运行

RUN addgroup -S spring && adduser -S spring -G spring
USER spring:spring

为什么要用非 root？安全！

如果你的容器被攻破了，黑客只获得了 spring 用户权限，而不是 root 权限，攻击面小很多。

5. 构建缓存优化

注意到这个顺序了吗？

COPY pom.xml .
COPY src ./src

先复制 pom.xml，再复制 src。这样如果只改了代码，pom.xml 没变，Maven 依赖就会直接用缓存，不用重新下载，速度提升 10 倍+。

# ❌ 错误
COPY --from=builder target/*.jar app.jar

# ✅ 正确（需要 WORKDIR /build）
COPY --from=builder /build/target/*.jar app.jar