容器镜像瘦身实战：从1.2GB到180MB的七步复盘

容器镜像瘦身实战：从 1.2GB 到 180MB 的七步复盘

很多团队第一次把 Java 或 Node 服务容器化时，镜像动辄 1GB 以上，推到镜像仓库慢、拉取更慢、节点磁盘三天两头告警。本文复盘一次真实的镜像瘦身过程：一个 Spring Boot 服务从 1.2GB 压到 180MB，冷启动时间从 40 秒降到 9 秒。所有结论都来自实测，踩过的坑一并记录。

一、先量化，再动手

瘦身之前必须先搞清楚"胖"在哪里。最省事的做法是把每一层拆开看体积。常用的方式是查看镜像历史：

docker history --no-trunc --format "{{.Size}}\t{{.CreatedBy}}" myapp:latest | sort -h -r | head -20

输出里往往一眼就能看到元凶：动辄 400MB 以上的构建工具层、残留的 apt 缓存、以及被复制进去的 .git 目录和 node_modules。另一个必查项是基础镜像本身的大小，很多人默认用 ubuntu 或 openjdk 官方镜像，光底座就 500MB 以上，还没开始装业务代码就已经输在起跑线。

我的经验是：先跑一次 docker images 和 docker history，把体积按"基础镜像 / 依赖 / 构建缓存 / 业务代码 / 临时文件"五类归因，再针对每一类下手。没有这步归因，后面的优化就是碰运气。

二、换更小的基础镜像

这一步收益通常最大。JDK 镜像有 clean 之外的多种选择：alpine 版（约 180MB）、slim 版、distroless 版。alpine 使用 musl libc，如果依赖了 glibc 相关的本地库会比较麻烦；distroless 更小但缺少 shell，排查问题不便。生产环境我一般选 slim 或 distroless。

需要注意的是，镜像小不等于安全。alpine 的 apk 包管理器仍然存在，意味着攻击面并没有消除。真正追求安全的话，distroless 加上非 root 用户运行才是更稳的组合。

三、多阶段构建，把构建工具留在上一阶段

这是瘦身里性价比最高的一招。典型的多阶段写法：

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

WORKDIR /src

COPY pom.xml .

RUN mvn -B dependency:go-offline

COPY src ./src

RUN mvn -B clean package -DskipTests

FROM eclipse-temurin:17-jre-alpine

WORKDIR /app

COPY --from=build /src/target/app.jar app.jar

RUN addgroup -S app && adduser -S -G app app

USER app

EXPOSE 8080

ENTRYPOINT ["java","-XX:MaxRAMPercentage=75","-jar","app.jar"]

关键点有三个：一是把依赖下载单独一层，利用层缓存，代码改动时不用重下依赖；二是最终镜像只复制 jar，不复制 target 目录；三是显式指定非 root 用户。很多人写了多阶段构建，却在最终阶段又 COPY . .，等于白做。

四、合并 RUN 指令，清理同一层内的缓存

Dockerfile 的每一条 RUN 都会生成一层，层与层之间的删除是"白删除"——文件仍然存在于下层。所以安装和清理必须在同一个 RUN 里：

RUN apk add --no-cache curl tzdata \

    && rm -rf /var/cache/apk/* /tmp/*

如果用 debian 系镜像，对应的是 apt-get update && apt-get install -y --no-install-recommends ... && rm -rf /var/lib/apt/lists/*。注意 --no-install-recommends，它会挡掉一大批"推荐但不需要"的包，常常能省下几十 MB。

五、写 .dockerignore，别把工作目录整个塞进去

这一条极容易被忽略，但收益立竿见影。没有 .dockerignore 时，COPY . . 会把 .git、node_modules、target、日志、测试数据全部带进构建上下文。曾见过一个项目仅 .git 目录就 300MB。

.dockerignore 至少要包含：.git、.idea、.vscode、node_modules、target、dist、*.log、.env、测试数据目录。顺便一提，减小构建上下文还能显著加快构建速度，因为上下文要先打包发给 daemon。

六、依赖分层与 jar 瘦身

Java 项目可以进一步把依赖拆成独立层：先复制依赖清单并执行解包，再复制应用类。这样改代码时依赖层完全复用缓存。Spring Boot 3 自带的 layertools 就是干这个的：

java -Djarmode=tools -jar app.jar extract --layers --destination extracted

分别 COPY dependencies、spring-boot-loader、snapshot-dependencies、application 四个目录，命中率会高很多。另外可以考虑 -Dspring-boot.repackage.excludes 排除不需要的 starter，或者用 jlink 裁剪 JDK 模块，针对只有 HTTP 场景的服务可以再省 40MB 左右。

七、验证与持续约束

瘦身不是一次性工程，很容易在几次迭代后反弹。建议做三件事：一是在 CI 里加镜像体积门禁，超过阈值直接失败；二是用 dive 工具检查每一层，找出可以进一步压缩的空间；三是定期扫描基础镜像的 CVE，镜像小但漏洞多并不是优化。

最终的实测结果：base 替换为 alpine JRE 后从 1.2GB 降到 420MB；多阶段构建去掉构建工具层降到 260MB；.dockerignore 去掉 .git 与 target 降到 195MB；jar 分层与依赖裁剪后稳定在 180MB。冷启动从 40 秒降到 9 秒，主要是因为镜像拉取时间大幅缩短，节点扩容响应明显变快。

一点补充建议

镜像瘦身只是容器化质量的一部分。同样的思路可以延伸到运行时：合理设置 resources.requests 与 limits，避免 Pod 因内存超限被 OOMKill；配置 liveness 与 readiness 探针，其中 readiness 要真正反映依赖可用性；日志统一输出到 stdout 交给日志采集，而不是写文件。在华为云 CCE 上部署时，建议为工作负载配置好节点亲和与反亲和，把同一服务的副本打散到不同节点，同时结合弹性伸缩策略设置合理的冷却时间，避免流量抖动导致频繁扩缩容。

最后提醒一句：优化指标要看"镜像体积"和"拉取耗时"，而不是单纯看层数。层数少的镜像不一定小，层数多的镜像也不一定慢，关键是每一层里的内容是否必要。