上周有个同事跑过来问我。说他打包的 Java 服务镜像有 1.2 GB，推到仓库慢得要命，部署拉镜像也得等半天。我一看他的 Dockerfile，好家伙。直接FROM openjdk:把整个 JDK 和 Debian 程序全打进去了。

镜像太大这件事，对业务造成了两大痛点：一是 CI/CD 速度被拖慢；二是安全和成本问题凸显，这篇文章就聊聊怎么把镜像从 1 GB 压到 100 MB 以内，让你在持续交付中不再为大镜像而头疼。

镜像为什么这么大？

先搞清楚体积都花在哪了。跑一下docker history myapp你会看到每一层的大小。大部分情况下的罪魁祸首就这几个：

• 用了一个臃肿的基础镜像。说起来，
• 建立工具和编译器留在了最终镜像里。
• 依赖缓存没清理，比如 apt 的/var/cachenpm 的node_modules。
• 源码、测试文件、文档全拷进去了。

说白了你的镜像里有一半东西在运行时根本用不到。

选对基础镜像

这是瘦身的第一步先，也是最马上见效的一步。其实，现在主流的轻量镜像有三选：Alpine、distroless、scratch。

• Alpine: 大概 5 MB 左右。基于 musl libc 和 busybox，自带包管理器 apk，有 shell。调试方便，但有些 C 语言依赖在 musl 上会踩坑。比如 glibc 特有的 DNS 解析行为。
• distroless: 更激进一些。只有你的应用运行时和最底层的共享库，没有 shell、没有包管理器。大小在 2~20 MB 之间，自带 SSL 证书。安全性好，但调试起来比较费劲——你没法 进去到处看。按理说，好在 distroless 提供了 :debug 标签。带了个 busybox shell，开发环境可以用。
• scratch: 是终极方案。 0 MB，完全空的文件程序。适合 Go、Rust 等编译成静态二进制的语言。其实，你的镜像里就只有编译好的可执行文件，别的什么都没有。但 SSL 证书得自己往里拷，调试也基本别想。

实际项目里怎么选？Go 应用我倾向 scratch 或 distroless；Java 应用用 distroless 的 Java 运行时；Node.js 用 Alpine。别用完整的 。换成 或 distroless 的 Java 镜像，体积直接砍掉一半。按理说，

多阶段建立是关键

This is core technique for slimming down images. The idea is simple: separate build environment from runtime environment,so that compilers and build tools do not end up in final image.

Maven + Spring Boot 示例：

# 建立阶段
FROM maven:eclipse-temurin AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:resolve
COPY src ./src
RUN mvn package -DskipTests
# 运行阶段
FROM eclipse-temurin:jre-alpine
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT

A first stage might be ~800 MB。but final image only pulls in JAR and switches to an Alpine JRE base—down to ~180 MB.

A Go project can be even slimmer:

FROM golang: AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o myapp -ldflags="-s -w" .
FROM scratch
COPY --from=builder /app/myapp /myapp
ENTRYPOINT

The flags strip debug info and enforce static linking so that scratch stays tiny.

不要忘记 .dockerignore！

.dockerignore 是让上下文保持干净的关键工具。如果它为空，“COPY . .” 会把整个项目目录。包括 .git、node_modules、测试文件和 IDE 配置一起拷进去，不仅让图像膨胀，还导致缓存失效频繁。说起来，

A minimal .dockerignore should contain at least:

.git/
nodemodules/
*.md
.env
Dockerfile
docker-compose.yml
pycache/
*.pyc
.idea/
.vscode/
target/
dist/
build/
tmp/
temp/
log/
logs/
*.log*
test/*
tests/*
specs/*
spec/*
coverage/*
vendor/
bowercomponents/

层缓存怎么调整？

• Mistake: putting `COPY . .` before `RUN npm install`. Every code change forces reinstall of dependencies.
• The right order : bash COPY package*.json . RUN npm ci COPY . . Only when package.json changes does npm re-run.
• Maven follows same pattern: `COPY pom.xml`。`RUN mvn dependency:resolve`,n `COPY src`.
• Merging RUN steps reduces layers: bash RUN apt-get update \ && apt-get install -y --no-install-recommends curl \ && rm -rf /var/lib/apt/lists/* The `--no-install-recommends` flag prevents unnecessary packages;clearing `/var/lib/apt/lists/*` keeps space free.

镜像扫描与安全性检查

• A smaller image is no good if it contains known CVEs. Run Trivy: bash trivy image myapp:latest The report tells you which layers are vulnerable and which dependencies need updates.
• An Alpine base may lag on security patches because it uses musl libc;distroless has less attack surface .
• Add scanning to your CI pipeline – fail builds on high‑severity vulnerabilities.

真实瘦身案例这方面，Node.js 项目从1.1GB降至98MB

FROM node:
WORKDIR /app
COPY .
RUN 
npm install
RUN 
npm run build
CMD "
}

FROM node:-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --omit=dev COPY --from=builder /app/dist ./dist CMD 压缩率：91% ↓ 从 1.1GB → 98MB CI/CD 推送/拉取时间显著缩短 成本与安全性双提高！说起来，

& 行动教程

• #基础选择：Apline/Distroless/Scratch 根据语言与需求挑选。话说回来，
• #多阶段建立：拆分建立与运行环境。让最终层只保留必需文件，
• #上下文过滤：.dockerignore 防止无关文件进入映射上下文。
• #层级缓存调整：COPY 与 RUN 顺序正确；合并 RUN 步骤并删除临时缓存。
• #安全扫描：trivy 或其他工具集成到 CI；高危漏洞直接阻止发布，

如果你还停留在“只要能跑就行”的思维模式，那你的团队将继续忍受长时间 CI 建立、不必要的数据传输还有潜在漏洞带来的风险。不妨先从上述五步开始改造。你会发现一次性投入数小时即可为后续每次推送和部署省下大量时间与成本——特别是在容器化持续交付流程中，这种收益更是不可估量。