Docker 镜像从 1.4GB 瘦到 90MB:多阶段构建、层缓存与 BuildKit 提速实战

真正逼我们下决心治理镜像的,是一次线上回滚。那天发布出了问题要紧急回滚,结果光是把上一个版本的镜像重新拉到节点上、再起容器,就等了将近十二分钟——镜像 1.4GB,节点上没缓存,只能从仓库一点点拉。那十二分钟里,故障一直在线上挂着,运营和老板的消息一条接一条。事后复盘,大家一致认为:一个连"快速回滚"都做不到的交付体系,本身就是最大的风险。于是我们花了点时间,把这个 1.4GB、构建一次要十二分钟的镜像,系统地优化到了 90MB、构建九十秒。

这篇不讲什么宏大的理论,就是一篇实打实的优化实录:从怎么量化镜像到底胖在哪开始,一刀一刀地砍,每砍一刀都记下镜像体积和构建耗时的变化,最后把这些手段沉淀成几条能直接抄的规矩。所有数字都是我们这个真实的 Go 服务镜像上测出来的。

先量化:镜像到底胖在哪

优化的第一步永远是测量,不是凭感觉乱删。镜像是分层的,每一条 Dockerfile 指令大致对应一层,要瘦身就得先知道每一层占了多少。docker history 能列出每层的大小,而 dive 这个工具更进一步,能告诉你每一层里到底加了什么文件、有多少是"加进去又在后面被删掉、但仍占着空间"的浪费:

# 看镜像每一层的大小,按指令对应
docker history --no-trunc --format "{{.Size}}\\t{{.CreatedBy}}" myapp:old

# 用 dive 逐层分析,重点看 "wasted space"(被覆盖/删除但仍占空间的文件)
dive myapp:old
# dive 给出的 efficiency score 只有 38%,意味着六成多的空间是浪费的
# 元凶很快浮出水面:完整的 golang 工具链(~800MB)、apt 缓存、源码、.git

分析下来,1.4GB 的镜像里真正运行需要的,只有那个编译出来的二进制和几个证书文件,加起来不到 30MB。剩下的全是"构建时需要、运行时根本用不上"的东西:Go 编译器和整套工具链占了八百多兆,基础镜像自带的一堆系统工具、apt 的包缓存、源代码、连 .git 目录都被打进去了。把这些分门别类列出来,瘦身的方向就一目了然:

第一刀:多阶段构建,把工具链留在门外

最大的一块肥肉是那 800MB 的 Go 工具链。它在构建时必不可少,但运行时一点用没有——服务跑的是编译好的二进制,不需要编译器。多阶段构建(multi-stage build)就是为这个场景设计的:在第一个阶段用完整的构建镜像把二进制编出来,在第二个阶段用一个干净的小镜像,只把那个二进制COPY过去,工具链、源码、依赖缓存全部留在第一阶段、不进最终镜像。

# ❌ 优化前:单阶段,编译器和源码全打进最终镜像,1.4GB
# FROM golang:1.22
# WORKDIR /app
# COPY . .
# RUN go build -o myapp .
# CMD ["./myapp"]

# ✅ 多阶段构建:builder 阶段编译,最终镜像只拿二进制
FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
# 静态编译,去掉 cgo 依赖,产出一个不依赖系统库的二进制
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /myapp .

# 最终阶段:从一个极小的基础镜像开始,只 COPY 二进制
FROM gcr.io/distroless/static-debian12
COPY --from=builder /myapp /myapp
COPY --from=builder /etc/ssl/certs /etc/ssl/certs
ENTRYPOINT ["/myapp"]

这里有两个小技巧值得说:-ldflags="-s -w" 去掉了二进制里的调试符号表,能再省十几兆;CGO_ENABLED=0 做静态编译,让二进制不依赖系统的 glibc 等动态库,这样最终阶段才能用 distroless 这种几乎什么都没有的镜像。这一刀下去,镜像从 1.4GB 直接掉到 **42MB**——光是把工具链请出门,就砍掉了 96% 的体积。

多阶段构建的数据流向,画出来是这样的:构建阶段是个"重"环境,产出物只有一个二进制;最终阶段是个"轻"环境,只接收那个产出物。中间隔着一道 COPY --from 的门,把一切构建时的累赘都挡在外面。

第二刀:挑对基础镜像

多阶段解决了"装了不该装的",下一个问题是"用了太重的底座"。最终阶段用什么基础镜像,直接决定了镜像的下限。常见的几个选择从重到轻是:完整发行版(ubuntu/debian)、瘦身版(-slim)、alpine、distroless,以及极端的 scratch(完全空白)。它们的差别不只是体积,还有调试便利性和兼容性的权衡:

我们最终选了 distroless/static。它里面连 shell 和包管理器都没有,只有运行静态二进制所必需的最小集合,体积只有 2MB,而且因为没有多余的程序,被攻击面也小。代价是没法 docker exec 进去 sh 一下调试——但我们觉得这个代价值得,调试可以靠日志和临时换 debug 镜像解决。如果你的程序依赖 glibc(比如用了 cgo),那 distroless/static 不适用,可以退一步选 alpine 或 distroless 的 base 变体。基础镜像的选择没有标准答案,核心是问自己:运行时到底需要哪些东西?把不需要的全部减掉,剩下的就是你该用的底座。

第三刀:层缓存与 .dockerignore,把构建时间砍下来

前两刀解决了体积,接下来轮到构建速度。我们最初的构建慢,很大一部分原因是没用好层缓存。Docker 构建时会逐层比对,只要某一层及其之前的内容没变,就直接复用缓存、跳过执行。但缓存有个铁律:一旦某一层变了,它后面的所有层缓存全部失效、都得重建。我们原来的写法是先 COPY . . 把整个项目拷进去,再 go mod download 拉依赖——这意味着只要改了任何一行业务代码,COPY 这层就变了,后面拉依赖那层缓存跟着失效,每次构建都要重新下载全部依赖,白白多花好几分钟。

正解是按"变化频率"给指令排序:越不容易变的放越前面。依赖清单(go.mod/package.json)变得少,先单独拷进去、拉好依赖;业务代码变得勤,放到最后再拷。这样改代码时,拉依赖那层的缓存依然有效,直接复用:

# ✅ 按变化频率排序:先拷依赖清单并下载(变化少,缓存命中率高)
COPY go.mod go.sum ./
RUN go mod download          # 只要 go.mod/go.sum 没变,这层永远命中缓存

# 再拷业务代码(变化频繁),放最后
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /myapp .
# 改代码时:上面的依赖层走缓存,只重跑 build 这一层

另一个常被忽视的点是构建上下文(build context)。执行 docker build 时,Docker 会先把当前目录的所有内容打包发给构建引擎,如果目录里有 .git、node_modules、日志、本地构建产物,这些都会被一起打包,既拖慢构建、又可能被误打进镜像。.dockerignore 就是用来排除它们的,作用和 .gitignore 一样:

# .dockerignore —— 把不该进构建上下文的东西挡在外面
.git
.gitignore
*.md
node_modules
dist/
build/
*.log
.env
.vscode
# 我们加上 .dockerignore 后,构建上下文从 180MB 降到 6MB,发送上下文这一步快了一个数量级

这两招配合下来,改一行代码触发的增量构建,从原来的"每次重拉依赖"的五六分钟,降到了三十秒以内。层缓存的本质是"复用没变的部分",而要让缓存可复用,你得主动把稳定的和易变的分开摆放——这是 Dockerfile 写法里性价比最高的一个习惯。

第四刀:合并 RUN、用完即清,别给垃圾留层

第四刀针对的是那些"装了又没清干净"的中间产物。每条 RUN 都会产生新的一层,而且层是只读叠加的——你在后一层删掉前一层的文件,前一层的空间并不会被释放,文件只是被"标记为删除"但仍占着体积。所以经典的错误是:一条 RUN 装包,另一条 RUN 清缓存,结果缓存其实还躺在前一层里,白清。

# ❌ 反例:分两层,清理无效,apt 缓存仍留在上一层占空间
# RUN apt-get update && apt-get install -y curl ca-certificates
# RUN rm -rf /var/lib/apt/lists/*       # 这层删的是上一层的,上一层体积不变

# ✅ 正解:安装与清理放在同一条 RUN,缓存根本不进入任何持久层
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl ca-certificates && \
    rm -rf /var/lib/apt/lists/* && \
    apt-get clean
# --no-install-recommends 还能避免装上一堆用不到的推荐依赖

要点有两个:一是安装和清理必须在同一条 RUN 里完成,这样临时产物在该层结束前就被删掉,根本不会被固化进镜像;二是 --no-install-recommends 这类参数能从源头少装东西。同样的原则适用于各种包管理器:npm 装完清 npm cache、pip 用 --no-cache-dir、apk 用 --no-cache。记住分层模型的特性:层是叠加的、不可减的,你能做的是从一开始就别让垃圾进来,而不是事后再删。

第五刀:BuildKit 缓存挂载,让依赖缓存跨构建复用

层缓存解决了"代码没变时复用依赖层",但还有个场景它救不了:当你确实改了 go.mod(加了个新依赖),依赖层缓存失效,就得把所有依赖重新下载一遍——哪怕其中 99% 的依赖上次已经下过了。传统层缓存是"全有或全无"的,没法做到"只下新增的那一个"。

BuildKit 的缓存挂载(cache mount)正是为此而生。它让你把依赖下载目录挂载成一个跨构建持久化的缓存卷,这个缓存不属于任何镜像层,而是独立存在、在多次构建之间共享。这样即便 go.mod 变了、依赖层重建,go mod download 也能命中那个持久缓存里已下好的包,只真正去下载新增的部分:

# syntax=docker/dockerfile:1.4
# 启用 BuildKit 缓存挂载:依赖缓存独立持久化,跨构建复用
FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
# 把 Go 的模块缓存和编译缓存挂成持久卷,不进镜像层
RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    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 /myapp .
# 启用方式:DOCKER_BUILDKIT=1 docker build .（新版 Docker 默认开启）

缓存挂载对前端 node_modules、Rust 的 ~/.cargo、Java 的 ~/.m2 同样适用,效果立竿见影。我们这个服务加上缓存挂载后,即便改了依赖,构建也能稳定在一分半以内,因为编译缓存(go-build)也被复用了,没改动的包不用重新编译。它和层缓存的关系是互补的:层缓存管"指令层面的复用",缓存挂载管"工具内部缓存的跨构建复用",两者叠加才能把构建时间压到最低。

第六刀:让 CI 也用上缓存,别每次都从零构建

本地构建快了,但 CI 上还是慢——因为 CI 的 runner 大多是临时的、每次任务起一个干净环境,本地积累的层缓存和缓存挂载它一概没有,等于每次都从零开始。要让 CI 也享受到缓存,核心是把缓存导出到一个 CI 能持久访问的地方(镜像仓库或 runner 缓存),下次构建时先导入。BuildKit 的 --cache-from / --cache-to 就是干这个的:

# GitHub Actions 里用 buildx 做带缓存的构建
- name: Set up Buildx
  uses: docker/setup-buildx-action@v3

- name: Build and push
  uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: myapp:${{ github.sha }}
    # 关键:把构建缓存读/写到镜像仓库,跨 CI 任务复用
    cache-from: type=registry,ref=myapp:buildcache
    cache-to: type=registry,ref=myapp:buildcache,mode=max
    # mode=max 会把所有中间层都缓存,命中率更高(体积换速度)
    platforms: linux/amd64

配上这个之后,CI 里只要依赖没变,依赖层和编译缓存全部命中远端缓存,构建时间从最初的十二分钟一路降到了九十秒,其中真正在跑的只剩"拷代码 + 增量编译"那点活。如果流水线里还有测试、lint、构建多个服务这些彼此独立的步骤,再把它们拆成并行 job,整体流水线的墙上时间还能进一步压缩。CI 提速的思路和本地一脉相承:识别出"没变就不该重做"的部分,想办法让它跨任务复用;识别出"互不依赖"的部分,让它们并行。

顺手做的运行时加固:别用 root 跑容器

瘦身的同时,有件几乎零成本却很值的事可以顺手做了:让容器以非 root 用户运行。很多镜像默认用 root 跑进程,一旦应用被攻破,攻击者拿到的就是容器内的 root 权限,风险面大。指定一个非特权用户来跑,是投入产出比极高的一条加固。distroless 镜像甚至直接提供了 nonroot 变体:

# 用 distroless 的 nonroot 变体,进程以 uid 65532 运行,非特权
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder --chown=nonroot:nonroot /myapp /myapp
USER nonroot
ENTRYPOINT ["/myapp"]
# 若用普通基础镜像,则自己建用户:
#   RUN adduser --disabled-password --no-create-home appuser
#   USER appuser

这条和瘦身是相辅相成的:distroless 本来就没有 shell 和包管理器,再加上非 root,容器即便被攻入,可操作的空间也极其有限。瘦身让镜像"东西更少",非 root 让进程"权限更小",两者叠在一起,镜像既轻又稳。这不属于专门的安全工程,只是把"运行时只保留最小必要"这个原则贯彻到了权限上而已。

六刀下来的累计效果

把每一刀的效果按顺序列出来,能很清楚地看到杠杆分别在哪——体积主要靠前两刀(多阶段 + 基础镜像),速度主要靠后三刀(层缓存 + 缓存挂载 + CI 缓存):

最终镜像稳定在 28~30MB(算上一些证书和时区数据),拉取和回滚都是秒级;CI 构建九十秒。回头看那次等了十二分钟才回滚成功的事故,现在同样的回滚不到十秒就完成了——这才是这一通优化最实在的价值:它买回来的不只是省下的存储和带宽,更是出事时能够快速止损的能力。

最终镜像该用哪个底座?照这棵树选

基础镜像的选择是整套优化里最需要权衡的一步,我把判断逻辑整理成一棵决策树:

我们后来定下的几条镜像规矩

这通优化之后,下面几条进了我们的 Dockerfile 模板和 CI 校验,新服务一律照此执行:

1. 一律多阶段构建:构建工具链绝不进最终镜像,最终阶段只 COPY 产出物。
2. 最终镜像用最小可行底座:静态二进制走 distroless/static,需要 glibc 的走 slim,能减的全减掉。
3. 按变化频率排列指令:依赖清单先拷先装,业务代码最后拷,最大化层缓存命中。
4. 每个项目都要有 .dockerignore,至少排除 .git、依赖目录、本地产物和 .env。
5. 安装与清理同一条 RUN,中间产物当层即清,绝不留到下一层。
6. 构建缓存要持久化复用:本地用 BuildKit 缓存挂载,CI 用远端缓存导入导出。
7. 容器以非 root 运行,显式 USER,不给进程多余权限。
8. 镜像体积纳入 CI 红线:超过约定阈值直接告警,不让镜像在不知不觉中重新胖回去。

几个反复见到的误区

这套优化推广到团队其他服务时,我发现有几个误区几乎每个人都会踩一次,这里专门拎出来说说,帮你少走弯路。

第一个误区是把镜像瘦身理解成"事后删文件"。经常有人在最后加一条 RUN rm -rf 想把镜像减肥,结果体积纹丝不动,然后百思不得其解。前面讲过,镜像层是只读叠加的,后一层删前一层的文件,空间并不会被释放。瘦身必须是"从一开始就不让它进来",而不是"进来之后再删"。真正能减体积的是多阶段构建、选小底座、同层清理这些"前置"手段,而非"后置"的删除。理解了分层模型,这个误区自然就破了。

第二个误区是盲目追求极致小而忽视可维护性。有人看到 scratch 能做到接近零体积,就一股脑全用 scratch,结果发现程序起不来——缺证书、缺时区数据、缺 CA bundle,排查半天。镜像不是越小越好,而是"恰好够用"最好。distroless 在体积和可用性之间取了个很好的平衡,大多数场景它就是终点,没必要为了再省那 2MB 去和 scratch 的各种缺失死磕。优化是有边际效应的,把力气花在前两刀的大头上,后面适可而止。

第三个误区是用 :latest 标签,以为方便其实埋雷。latest 是个会变的浮动标签,今天拉到的和明天拉到的可能是两个不同的镜像,这让"回滚到某个确定版本"变得不可靠,也让构建缓存的行为变得难以预测。正确做法是用不可变的标签——用 git 的 commit SHA 或语义化版本号给镜像打标,每个标签永远指向同一个镜像。这样回滚就是确定的:回到哪个 SHA,就是哪个 SHA,不会有任何意外。这条看似和体积无关,却是"快速可靠回滚"这个目标里不可或缺的一环。

第四个误区是优化完就不管了,任由镜像慢慢胖回去。镜像体积是会"熵增"的:今天有人加了个临时调试工具忘了删,明天有人图省事换回了完整基础镜像,几个月后镜像又悄悄涨回几百兆。所以最后一条规矩——把镜像体积纳入 CI 红线——特别重要。让机器在每次构建时盯着体积,超过阈值就告警,才能让这套优化的成果长期保持,而不是优化一阵、反弹一阵。

写在最后

整理完这套优化,我最大的感受是:镜像瘦身和构建提速,看着是一堆零碎的 Dockerfile 技巧,但背后其实是同一个朴素的原则反复出现——只保留运行时真正需要的东西,只重做真正变化了的部分。多阶段构建是在做"运行时不需要工具链",选小底座是在做"运行时不需要那些系统工具",层缓存和缓存挂载是在做"没变的依赖不重新拉、没变的代码不重新编"。把这个原则吃透,你遇到任何新的构建场景,都能自己推导出该怎么优化。

而这一切的终点,也不是镜像数字本身好看,而是交付这件事变得轻快、可靠:拉取快、回滚快、CI 反馈快。一个能在十秒内完成回滚的系统,和一个回滚要等十二分钟的系统,在真正出事的那一刻,差的不是几分钟,而是从容和慌乱的区别。把交付的每一个环节都打磨利落,等于在平时就为将来某个糟糕的时刻,悄悄买好了保险。说到底,镜像优化从来不是一件追求数字漂亮的面子工程,而是一项关乎稳定与效率的基本功——它值得你在每一个新服务上线之初,就把这几刀认认真真地用上。

—— 别看了 · 2026