Docker 镜像瘦身实战:从 1.8GB 到 23MB,多阶段构建与分层缓存

那次上线我记得很清楚:CI 流水线卡在"拉取镜像"那一步整整八分钟,然后 Kubernetes 节点弹出磁盘告警,几个 Pod 因为拉不下镜像一直 ImagePullBackOff。我去看了一眼镜像大小——1.8GB。一个用 Go 写的、二进制本身才十几兆的小服务,镜像居然有将近两个 G。那一刻我才意识到,我们团队那个写了快一年、所有人复制粘贴的 Dockerfile,从头到尾就没人认真看过它到底把什么东西打进了镜像。

这篇就从那个 1.8GB 的镜像讲起,把它一步步瘦到 80MB 出头:镜像为什么会胖、怎么看清它胖在哪、分层和缓存到底是怎么回事、多阶段构建为什么是瘦身的核武器、基础镜像该怎么选、层的顺序如何决定你每次构建是十秒还是十分钟。这些东西没有一个是玄学,全都写在镜像的分层结构里,看懂了,瘦身就是顺手的事。

先搞清楚:镜像为什么会胖成这样

在动手之前,得先知道一个镜像的体积都被什么吃掉了。Docker 镜像是一层一层叠起来的,Dockerfile 里几乎每条指令都会生成新的一层,而且——这点最关键——每一层都是只读的、累加的,前面的层删不掉后面层的内容。你在第十层 rm 掉的文件,如果它是第三层加进来的,镜像体积根本不会变小,那个文件还原封不动躺在第三层里。下面是把镜像撑大的几个最常见来源:

我们那个 1.8GB 的镜像,几乎把上面五条占全了:用的是 golang:1.21 全量镜像(光这个基础镜像就 800 多兆,里面带着完整的 Go 工具链),然后在同一个镜像里编译、跑测试、最后直接 CMD 启动——编译器、源码、模块缓存,全都原封不动留在了最终镜像里。运行时其实只需要那个十几兆的二进制,但我们扛着整套构建环境上了生产。

第一件事:别猜,看清它到底胖在哪

瘦身的第一步永远不是"我觉得",而是把镜像每一层的体积摊开看。docker history 就能干这事,它会列出镜像的每一层以及对应的指令和大小:

# 按层查看镜像体积,--no-trunc 看完整指令,--human 友好显示
docker history my-service:latest --no-trunc --format "table {{.Size}}\t{{.CreatedBy}}"

# 输出大概长这样(精简过):
#   SIZE      CREATED BY
#   12.3MB    CMD ["/app/server"]
#   0B        COPY /app/server /app/server
#   1.1GB     RUN go build && go test ./...   <-- 凶手在这,构建层 1.1G
#   780MB     FROM golang:1.21                 <-- 基础镜像就 780M

看到没,真正运行需要的二进制只有 12MB,但它下面压着一个 1.1GB 的构建层和一个 780MB 的基础镜像层。光靠 docker history 你已经能定位到大头。如果想看得更细——具体是哪个文件、哪个目录占了空间,推荐一个叫 dive 的工具,它能逐层钻进去看文件树,还会给出一个"浪费了多少空间"的评分:

# dive 逐层分析镜像,能看到每层新增/修改/删除了哪些文件
dive my-service:latest

# 它会算出一个 efficiency score,以及"这些层里有多少是被后面层覆盖/删除的无效空间"
# wastedBytes 很高,基本就说明你有"假删除"——前面加后面删,体积白占

这一步的意义在于:瘦身是有靶子的工程,不是凭感觉乱删。先用 docker history 看清哪一层最胖,再用 dive 钻进去看那层里到底是什么,你才知道该往哪儿下刀。我们当时一看就清楚了——大头就两个:全量基础镜像,和把构建过程留在最终镜像里。这两刀下去,1.8G 能砍掉一大半。

第二件事:理解分层与缓存,这是一切的基础

要瘦身、也要让构建快,你必须先理解 Docker 的分层缓存机制。前面说过,Dockerfile 每条指令生成一层;而构建时,Docker 会尽量复用上一次构建的层缓存——只要某一层的指令和它依赖的内容没变,这一层和它之前的所有层就直接命中缓存,秒过。但有一条铁规则:一旦某一层失效(指令变了,或它 COPY 的文件变了),从这一层往后的所有层缓存全部作废,必须重新构建。

这张图藏着层顺序优化的全部秘密:把不常变的放前面,常变的放后面。依赖清单(go.mod、package.json)几天才动一次,源代码可能一分钟改八遍。如果你先 COPY 全部源码再下载依赖,那每次改一行代码,依赖层就跟着失效、重新拉一遍几百兆的包;反过来,先单独 COPY 依赖清单、装好依赖,再 COPY 源码,那改代码时依赖层稳稳命中缓存,构建从几分钟变几秒。这个顺序问题,后面第六件事还会专门拿代码说。

第三件事:多阶段构建——瘦身的核武器

定位清楚之后,真正能把 1.8G 砍到几十兆的,是多阶段构建(multi-stage build)。它的思路简单到优雅:用一个"重"的镜像去编译,编译完只把那个产物拷到一个"轻"的镜像里,把整个构建环境彻底丢掉。先看我们当初那个反面教材:

# 反面教材:单阶段,构建环境全留在最终镜像里
FROM golang:1.21          # 780MB 的全量镜像,带整套 Go 工具链
WORKDIR /app
COPY . .                  # 整个仓库,包括 .git、测试、各种乱七八糟的文件
RUN go build -o server .  # 编译,但 go 编译器、模块缓存全留下了
RUN go test ./...         # 测试产物也留下了
CMD ["./server"]
# 结果:最终镜像 = 780M 基础 + 源码 + 编译器缓存 + 测试残留 ≈ 1.8GB

问题一目了然:最终跑起来只需要 server 这一个二进制,可镜像里却扛着整个 Go 工具链、源码、模块缓存。多阶段构建把"编译"和"运行"拆成两个阶段,只让运行阶段进入最终镜像:

# 正解:多阶段构建,builder 阶段编译,最终镜像只要二进制
# ---- 阶段一:builder,用重镜像编译 ----
FROM golang:1.21 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download                          # 依赖单独一层,利于缓存
COPY . .
# 关掉 CGO + 去掉调试信息,产物更小、更独立(不依赖 glibc)
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /server .

# ---- 阶段二:运行镜像,只拷贝产物 ----
FROM alpine:3.19                             # 仅约 7MB
RUN apk add --no-cache ca-certificates       # 只补运行真正需要的(如 HTTPS 根证书)
COPY --from=builder /server /server          # 关键:只从 builder 拷出那个二进制
ENTRYPOINT ["/server"]
# 结果:7M 基础 + 1~2M 证书 + 十几兆二进制 ≈ 20MB 上下

核心就在 COPY --from=builder 这一句:它从前一个阶段里只拎出那个编译好的二进制,编译器、源码、缓存全部留在了 builder 阶段,而 builder 阶段根本不会进入最终镜像。我们当时换成这套写法,镜像直接从 1.8GB 掉到了 23MB——砍掉了 98%。这就是为什么我说多阶段构建是核武器:它从根上解决了"构建环境污染运行环境"这个最大的胖源。

第四件事:基础镜像选对,又是一大块

多阶段构建解决了"构建环境"的问题,而最终镜像还剩一个变量:运行阶段用什么基础镜像。同一个二进制,塞进不同的基础镜像,体积能差出十倍。常见的几档,从重到轻:

选哪个有个朴素的判断:你的程序运行时真正依赖什么,就选刚好满足它的最小镜像。纯静态编译的 Go 程序(CGO_ENABLED=0),理论上 scratch 都能跑——但 scratch 里连根证书、时区文件都没有,发 TLS,在 HTTP 之上加一层 TLS 加密,防止中间人窃听和篡改。">HTTPS 请求会失败,所以实践中我更偏向 alpine:补一个 ca-certificates 就够了,还留了个 shell 方便偶尔进去看一眼。如果是 Java/Node 这类需要运行时的,就别硬上 alpine 找 musl 的麻烦,distroless 或 slim 通常更省心。我们最终选了 alpine,从 builder 那套换过来后稳定落在 23MB。

第五件事:.dockerignore 和"一层做完一件事"

还有两个小而值钱的细节。第一个是 .dockerignore——它和 .gitignore 一个意思,告诉 COPY . . 别把哪些东西拷进镜像。没有它,你的 .git 目录、本地 node_modules、日志、临时文件全会被打进 builder 阶段,既拖慢构建上下文上传,又可能把敏感文件(比如 .env)泄进镜像:

# .dockerignore —— 放在构建上下文根目录
.git
.gitignore
*.md
node_modules
dist
*.log
.env
.env.*
test/
**/*_test.go
Dockerfile
.dockerignore

第二个是包管理器的缓存清理,而且必须和安装写在同一个 RUN 里。这正好呼应前面说的分层规则——如果你这一层装包、下一层清缓存,缓存其实留在了上一层删不掉(假删除)。必须在同一层装完就地清:

# 错的:分两层,缓存留在上一层,体积白占
RUN apt-get update && apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*     # 没用!curl 那层的 apt 缓存还在

# 对的:同一个 RUN 里装完就清,缓存根本不进入这一层
RUN apt-get update \
    && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*

# alpine 更省事,--no-cache 直接不留缓存
RUN apk add --no-cache curl

这两点单独看省得不多,几十兆而已,但它们和分层规则是同一套底层逻辑:体积是按层累加的,你想让某个东西不占体积,就得保证它从一开始就没进入任何一层,而不是事后去删。

第六件事:层顺序——决定你每次构建是十秒还是十分钟

瘦身解决了"镜像多大",层顺序解决的是"每次构建多快"。前面第二件事那张图说过缓存的铁规则:一层失效,其后全部失效。把这条规则落到 Dockerfile 上,就是一句话——把最不容易变的指令放最前面,最容易变的(源代码)放最后面。看一个我们改之前、改之后的对比:

# 慢:先 COPY 全部源码,再装依赖
FROM node:20-slim AS builder
WORKDIR /app
COPY . .                  # 源码一变(哪怕只改一行),这层就失效
RUN npm ci                # 于是依赖层跟着失效,每次都重装几百兆 node_modules
RUN npm run build
# 后果:改一行业务代码 = 重新 npm ci,构建动辄三五分钟

# 快:依赖清单先行,源码最后
FROM node:20-slim AS builder
WORKDIR /app
COPY package.json package-lock.json ./   # 只拷清单,它很少变
RUN npm ci                                # 清单没变 → 这层命中缓存,秒过
COPY . .                                  # 源码放到装完依赖之后
RUN npm run build
# 后果:只改业务代码时,npm ci 直接命中缓存,构建几秒钟

两份文件做的事一模一样,产物也一样,差别只在 COPY 的粒度和顺序。第一份把"装依赖"这个昂贵又不常变的操作,绑死在了"改一行就变"的源码层后面;第二份把它解绑,让它能稳稳吃到缓存。我们那个前端服务改完这一处,CI 里的镜像构建从平均 4 分钟降到了 20 秒上下——没动一行业务代码,纯靠把指令顺序摆对。这也是为什么我说,Dockerfile 不是脚本,是一份需要照着分层缓存规则去设计的"声明":每一行放在哪、拷多大粒度,都在悄悄决定你团队每天要等多少分钟。

把整套思路收成一棵决策树

把前面六件事串起来,下次拿到一个该优化的镜像,照着这棵树走就行,不用凭感觉:

这棵树的根上是那个最该先问自己的问题:我要解决的到底是"镜像大"还是"构建慢"?这俩是两条不同的优化线——镜像大,往多阶段构建和基础镜像上使劲;构建慢,往层顺序和构建上下文上使劲。它们偶有重叠(比如 .dockerignore 两头都帮),但药方不同,先分清你疼的是哪一个,再对症。

收口成几条镜像优化的铁律

1. 能多阶段就多阶段:任何"编译型"语言(Go/Java/Rust/前端打包)都该把构建和运行拆开,最终镜像只 COPY --from 拷产物,这是性价比最高的一刀。
2. 运行镜像选最小够用的:静态二进制用 scratch/alpine,带运行时的用 distroless/slim,别拿全量 ubuntu 当运行底座。
3. 装包和清缓存写进同一个 RUN:分两层删等于没删(假删除),缓存还压在上一层里占体积。
4. 依赖清单先 COPY、先安装,源码最后 COPY:让昂贵的依赖层吃满缓存,改代码不再触发重装。
5. 永远配 .dockerignore:挡住 .git、node_modules、日志、.env,既瘦身又防敏感文件泄漏进镜像。
6. 记住"层是只读累加"这条物理规则:想让某样东西不占体积,要保证它从没进入任何一层,而不是事后 rm。
7. 改完一定量化验证:用 docker history 看体积、给构建计时,别只凭"感觉变快了"。

几个特别容易踩的认知误区

这套经验讲给同事听时,有几个误解几乎人人都有,值得专门点破。

第一个、也是最普遍的:"镜像大点无所谓,反正能跑。" 它的代价是隐性但实打实的:拉取慢(扩容、滚动更新时每个节点都要拉)、占满节点磁盘触发驱逐、CI 缓存和镜像仓库成本上升、攻击面变大(镜像里每个多余的包都是潜在漏洞)。我那次 ImagePullBackOff 就是大镜像在扩容时的现世报——平时不疼,真要紧的时候要命。

第二个误区:"我在 Dockerfile 最后 rm 掉了,体积就小了。" 这是对分层最常见的误解。rm 只是在新的一层记录了"这个文件被删除",被删的文件本体还躺在它被加入的那一层里,镜像总体积纹丝不动。要真减体积,要么一开始就别把它装进来(多阶段、.dockerignore),要么装和删写在同一层。

第三个误区:"alpine 最小,所有项目都该用 alpine。" alpine 用的是 musl libc,和主流的 glibc 不完全兼容。Python 带 C 扩展的包可能要重新编译(构建慢到怀疑人生)、某些预编译的二进制直接跑不起来、还遇到过 DNS 解析行为不一致的坑。alpine 是个好默认,但不是无脑选项——带复杂运行时的项目,distroless 或 debian:slim 往往更省心,省下的是你排查兼容性问题的时间。

第四个误区:"层顺序只是风格问题,怎么写都能跑。" 能跑,但每天都在偷走你团队的时间。顺序错了,改一行代码就触发几百兆依赖重装,一天几十次构建,累计起来是几个小时的等待。Dockerfile 的每一行顺序都是在和缓存做交易,摆对了,缓存替你干活;摆错了,你替缓存还债。

再进一阶:让依赖缓存跨构建复用,而不进镜像

把层顺序摆对之后,还有一个更隐蔽的浪费:当依赖清单确实变了的时候,缓存照样整层失效,得把所有依赖从零拉一遍。加一个包、升一个版本,go.mod 一动,go mod download 那层就失效,几百兆模块全部重下——哪怕九成九的包其实没变。层缓存是"全有或全无"的,它救不了这种场景。

BuildKit(新版 Docker 默认的构建引擎)给了一个漂亮的解法:缓存挂载(--mount=type=cache)。它让某个目录(比如 Go 的模块缓存、npm 的缓存、apt 的缓存)在多次构建之间持久保留,但这个缓存目录本身不会被打进镜像层。换句话说,它把"下载缓存"和"镜像体积"彻底解耦了——缓存照样复用,镜像照样干净:

# syntax=docker/dockerfile:1   <-- 必须有这行,启用 BuildKit 新语法
FROM golang:1.21 AS builder
WORKDIR /app
COPY go.mod go.sum ./
# 把 Go 模块缓存挂成持久缓存:即便 go.mod 变了,没变的包也不用重下
RUN --mount=type=cache,target=/go/pkg/mod \
    go mod download
COPY . .
# 编译缓存同理挂载,增量编译快得多;两个缓存都不进入最终产物层
RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    CGO_ENABLED=0 go build -ldflags="-s -w" -o /server .

前端、Python 是一个道理,把对应的缓存目录挂上去就行:

# npm:挂载 npm 缓存目录
RUN --mount=type=cache,target=/root/.npm \
    npm ci

# pip:挂载 pip 缓存目录
RUN --mount=type=cache,target=/root/.cache/pip \
    pip install -r requirements.txt

这里要拎清一个容易混的点:层缓存和缓存挂载解决的是两件不同的事。层缓存让"依赖没变时整层跳过"——它是粗粒度的、全有或全无;缓存挂载让"依赖变了时,只补下载变化的部分"——它是细粒度的、增量的。两者叠加,才是构建速度的最优解:依赖没动时层缓存直接秒过,依赖动了时缓存挂载兜底,只补差量。而且因为挂载的缓存不进镜像,你既享受了缓存的快,又没付出体积的代价——这正好是本文从头到尾那条主线的延伸:让该快的快,让不该进镜像的东西,从一开始就别进镜像。

顺手提一句:别让 latest 毁掉可复现

瘦身和提速之外,还有一个和镜像质量强相关、却常被忽略的习惯:固定基础镜像的版本,别用 latest。我见过太多 Dockerfile 第一行写 FROM node:latest 或 FROM golang(不带 tag,默认就是 latest),结果几个月后某次重建,基础镜像悄悄跟到了一个大版本,编译直接报错,或者更阴险——能编过、能跑,但行为变了,排查半天才发现是底座换了。latest 意味着"今天和明天构建出的可能是两个不同的镜像",这和可复现是直接冲突的。

# 别这样:latest 会随时间漂移,构建不可复现
FROM golang:latest

# 至少固定到次版本:
FROM golang:1.21

# 要极致可复现,连摘要(digest)一起钉死,任何人任何时候拉到的都是同一个镜像:
FROM golang:1.21.6-alpine3.19@sha256:abc123...

钉到次版本(1.21)是日常的合理折中:能吃到补丁更新,又不会跳大版本。要做到字节级可复现(比如安全合规、审计要求),就把 @sha256: 摘要也钉上——这样无论谁、在哪台机器、什么时候构建,FROM 拉到的都是同一个镜像。这条和瘦身看似无关,实则同源:镜像是你交付的最终产物,它的体积、速度、可复现性,都该是被设计出来的确定结果,而不是放任 latest 和复制粘贴的 Dockerfile 替你随机决定。

写在最后

回到那个 ImagePullBackOff 的下午。最终的修复其实就两件事:把单阶段 Dockerfile 改成多阶段、运行镜像换成 alpine,再把依赖层挪到源码前面。镜像从 1.8GB 掉到 23MB,CI 构建从 4 分钟降到 20 秒,扩容时再没卡在拉镜像上。改动加起来不到二十行,难的从来不是改,而是搞懂"为什么会这样"——而那要求我把 Docker 的分层模型、缓存规则、构建与运行的边界,真正想明白一遍。

这件事给我最深的体会是:Dockerfile 不是一堆复制粘贴就能用的咒语,它是一份需要照着镜像物理结构去设计的声明。层是只读累加的、缓存是逐层失效的、构建环境不该污染运行环境——这几条朴素的规则,决定了你的镜像是 1.8GB 还是 23MB、构建是十分钟还是十秒。下次再接手一个臃肿的镜像,别急着上网搜"Docker 瘦身十个技巧",先 docker history 看一眼它到底胖在哪——答案,往往就清清楚楚地写在那一层层的体积里。

—— 别看了 · 2026