容器镜像体积优化的实用技巧

容器镜像的体积经常被忽视，直到发现拉取镜像要等三分钟、节点磁盘三天就满、CI 流水线一半时间花在 push 上。镜像体积不是一个"好看"的指标，它直接影响部署速度、存储成本和攻击面。这篇文章整理几类实际有效的优化手段。

先搞清楚体积花在哪

动手之前先测量。用 docker history <image> 能看到每一层的体积，用 dive 这类工具可以逐层看文件变化。常见的情况是：基础镜像 800MB、依赖 300MB、构建产物 200MB、临时文件 150MB——优化收益最大的往往是第一步而不是第三步。

一、换更小的基础镜像

这是收益最高的一刀。ubuntu:22.04 约 77MB，debian:bookworm-slim 约 74MB，alpine 只有 7MB。从 ubuntu 换到 alpine 通常能省 90% 的基础层。

但要注意 alpine 用 musl libc 而不是 glibc。Node.js 的某些原生模块、Python 的科学计算包在 alpine 上要么装不上，要么需要编译（反而让镜像更大）。这类场景更适合 distroless 或者 debian-slim。别为了体积把运行时搞坏。

二、多阶段构建

编译工具链（gcc、make、node-gyp、Maven）在运行阶段完全用不上，但它们往往占几百 MB。多阶段构建让构建环境和运行环境分离，最终镜像只带运行时和产物：

FROM golang:1.22 AS builder
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app

FROM alpine:3.19
COPY --from=builder /app /app
ENTRYPOINT ["/app"]

一个典型的 Go 服务能从 900MB 降到 15MB。前端项目同理：node 容器里 build，只把 dist 拷到 nginx 镜像。

三、合并 RUN 指令并清理缓存

Dockerfile 里每条 RUN 都会产生一层，层是叠加的——你在后一层删掉的文件，在前一层里依然占体积。所以要在同一个 RUN 里装完立刻清：

RUN apt-get update \
 && apt-get install -y --no-install-recommends curl \
 && rm -rf /var/lib/apt/lists/*

关键点有三个：--no-install-recommends 避免拉一堆用不上的推荐包；rm -rf 清理包管理器的索引缓存；把 update/install/clean 写在同一条 RUN 里。npm 场景对应的是 npm ci --omit=dev && npm cache clean --force。

四、用好 .dockerignore

很多人漏了这一步。COPY . . 会把 .git、node_modules、测试数据、日志全打进镜像。.git 目录动辄几十上百 MB。写一个 .dockerignore，把这些排除掉，往往能立竿见影省 50MB 以上。

五、压缩与去重

二进制文件可以 strip 掉符号表（Go 加 -ldflags="-s -w"，C/C++ 用 strip），通常能减 20-30%。如果镜像里有多份相同的依赖（比如多个 Python 包各自带一份 openssl），考虑提取到公共层。另外启用 registry 的压缩存储也能减少传输量。

六、把变化少的放前面

这条不减小体积，但极大提升构建效率：Dockerfile 里先 COPY 依赖清单（package.json / requirements.txt / go.mod）并安装依赖，再 COPY 源码。这样改代码时依赖层能命中缓存，不用重装。

优化的边界

不要过度优化。为了省 5MB 把镜像拆得难以维护，不值得。经验值是：基础镜像选对 + 多阶段构建 + 清理缓存 + .dockerignore，这四步能拿到 80% 的收益，剩下的边际成本很高。

最后提醒一句：镜像瘦身不只是省存储。镜像越小，拉取越快（弹性扩容更快）、层越少（漏洞扫描越清晰）、装的包越少（CVE 越少）。这是同时改善性能、成本和安全的少数优化之一。