Docker 镜像体积优化：从 1.2GB 压到 180MB 的四个实际步骤

Java 服务的 Docker 镜像动辄上 GB，构建慢、推送慢、拉取慢。这篇记录一次把镜像从 1.2GB 压到 180MB 的实际过程，每一步都有实测数字。

一、先看清体积到底在哪

docker history --human --no-trunc my-app:latest | sort -k1 -h | tail -10
dive my-app:latest

docker history 已经能看到每层大小。dive 更直观，能进到每一层看具体哪些文件占空间。多数情况下一眼就能看到「基础镜像」占了大头。

二、换基础镜像：1.2GB → 420MB

# 之前
FROM openjdk:8
# 之后
FROM eclipse-temurin:17-jre-alpine

openjdk:8 是完整 JDK + 完整 Debian，接近 800MB。只跑 jar 包不需要编译器，用 JRE 就够；alpine 变体再省一层。这一步省掉的体积最多，但要注意 alpine 用 musl libc，有 native 依赖的项目得先验证。

三、多阶段构建：420MB → 210MB

FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn package -DskipTests

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /build/target/*.jar app.jar
ENTRYPOINT ["java","-jar","app.jar"]

关键点有两个：先把 pom.xml 单独 COPY 再跑 go-offline，这样依赖层能被缓存，改代码不用重新下载依赖；最终镜像里只保留 jar，Maven、源码、.git 全都不进去。

四、清理与精简：210MB → 180MB

• 同一条 RUN 里装完就删缓存：apk add --no-cache，或 rm -rf /var/cache/apk/*
• 用 .dockerignore 排除 target/、.git/、node_modules/，否则 COPY 会把整个目录塞进构建上下文
• Spring Boot 项目可以开分层 jar：layertools 把依赖和业务代码分层，改代码只重推最上面一层

五、别做的事

• 不要为了压体积把 JRE 换成 jlink 自定义运行时——除非你清楚模块依赖，否则很容易在运行时才暴露缺失模块
• 不要用 --squash：层被合并后无法复用缓存，每次构建都全量重来，省下的体积不抵构建时间的损失
• 不要在最终镜像里保留 curl、vim 这类调试工具，需要时用 docker exec 进临时容器排查

四个步骤下来，同一个服务从 1.2GB 降到 180MB，推送时间从 4 分钟降到 20 秒。体积优化真正省的不只是磁盘，而是每次发布的等待时间。