跑 Docker 久了你会发现，镜像会越来越臃肿：同一个镜像里既有编译工具又有运行时依赖，动辄几百 MB；仓库里躺着好几个 tag，硬盘悄悄被占满；每次构建，改一行代码也要把一层层缓存重打。这些"镜像越来越重、构建越来越慢"的体验，根子往往不在应用本身，而在镜像的构建方式。Docker 多阶段构建（multi-stage build）与镜像瘦身，正是解决这类"如何把镜像做小、做快、做正确"问题的主战场。这篇讲清多阶段构建解决什么、它和单阶段构建的本质区别、怎么写一段多阶段+瘦身的 Dockerfile、以及镜像缓存与安全修复的实践边界。
一、多阶段构建解决什么：别把"编译环境"和"运行环境"塞进同一个镜像
很多镜像臃肿的根源，是"用一个镜像既装编译工具又跑最终应用"：为了编译，你得在镜像里带编译器、构建依赖、源码和一堆临时中间文件，但这些在生产运行时根本用不到——它们白白把镜像撑大、增大攻击面。多阶段构建的核心思想就是：用多个临时阶段分别做各自擅长的活（如在第一阶段"编译"，在第二阶段"仅拷贝编译产物 + 运行时依赖"），最终只把最后阶段的产物打包成镜像。这样编译器、中间文件都不会进入最终镜像。
它解决了三件事：一是"镜像更小"，只留运行时所需；二是"复用与隔离"，同一套 Dockerfile 可含多个阶段服务不同目的（build / test / runtime）；三是"铲掉中间物"，不再靠 `rm -rf` 事后清除能清的有限。对自托管者特别实用：你几乎总希望自己部署的镜像足够小、足够干净，多阶段构建是把"会构建"升级成"会正确构建"的关键一步。
二、最小的多阶段：两段式"编译 → 只拷成品"
多阶段最典型的形态是两段式：第一阶段用一个带编译工具链的镜像（往往较大，如 golang/node 官方镜像）完成构建；第二阶段从一个"仅含运行时"的小基镜像（如 alpine、slim 变体）开始，仅 `COPY --from=第一阶段` 把编译产物复制进来。最终镜像 = 第二阶段的产物，第一阶段的编译器、源码、依赖全部不进入产物。
# 阶段一：构建（会用到编译工具链）
FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /app/bin ./cmd/app
# 阶段二：运行时（只拷产物，用极小的运行时镜像）
FROM alpine:3.20
RUN apk add --no-cache ca-certificates tzdata
COPY --from=build /app/bin /usr/local/bin/app
# 需要的静态资源同样用 --from 拷入
USER nobody
ENTRYPOINT ["/usr/local/bin/app"]
这段想表达的关键点：`--from=build` 是你的桥，让第二阶段的最终镜像拿到第一阶段产物而不带第一阶段环境；`USER nobody` 用非 root 跑、`ca-certificates` 补齐证书信任，都是让镜像"能跑且安全"的小细节。写多阶段时最容易犯的错是"忘了最终阶段的清瘦"——记得凡在最终阶段用不到的东西都不要拷进去，只留运行必需的二进制、配置与少量资源。
三、镜像瘦身的几条实操：基础镜像、无根、压缩、未用依赖
除了多阶段，镜像瘦身还有几招常搭着用。一是选对"基础镜像"：能用 alpine/slim 这类精简版就用，但也要警惕"有的人为了小的 flag 硬换基础镜像导致不兼容"——小和有 compatibility 要权衡，别为了多省几 MB 牺牲运行时依赖。二是"压缩二进制"（如 Go 的 `-ldflags="-s -w"`、对源码做好 Release build）能减小产物体积。三是"只装运行依赖"：别把 debug 工具、未用的包带进最终镜像；四是用 `.dockerignore` 挡掉本地不该进 build context 的垃圾（node_modules、.git、临时文件），少了它们也显著加快构建与减小镜像。
# .dockerignore 防止把本地大目录/垃圾文件打进构建上下文
node_modules
.git
*.log
dist-cache
把这些组合成习惯后，你的镜像通常会比原来的"全家桶"瘦下一大截。落地建议是"先衡量再瘦身"：用 `docker images` 与 `docker history` 看镜像各层占用，找出占用大头，再针对性地用多阶段/选基镜/剔未用依赖去减；并设一个"能接受的下限"，不必为零而零。最直接的做法是先用朴素方式看到"哪一层最重"，再动手，比盲目优化效率高得多。
四、镜像缓存与构建体验：改得快、发得顺
构建慢的另一个大头是"缓存没用好"。Docker 给 Dockerfile 的每一层做缓存，层的输入变了才会重建该层及其后的层。所以"把易变的 COPY 放后面"就能让缓存复用更多：先 `COPY` 依赖清单并把依赖安装层做在前面（通常不那么变），再 `COPY` 常变的源码；这样你改代码时，只有后面的层会重建，前面的依赖层直接命中缓存，构建大幅变快。反过来的坏习惯是"在一开始就 COPY 全部源码"，导致任何改动都从最前面重新走。
# 善用缓存：先把依赖层放前、常变的源码放后
COPY go.mod go.sum ./
RUN go mod download # 依赖变了才重建这层
COPY . . # 只动源码时，上面的层命中缓存，很快
另一个体验要点是把"最终镜像用非 root + 只读运行数据"当成默认：容器里以非特权用户跑、把需要写的目录以数据卷/只读处理，既能减小权限风险面，也能避免"容器里乱写导致镜像涨/层不稳定"的困扰。把"缓存顺序 + 依赖先行 + 非 root + 只读"用顺，构建和发布体验会从"每次重打整个镜像"变成"改哪里重打哪里、又快又稳"。
五、安全与边界：小、快之外，别忘了"能长期更新"
追求镜像瘦身时有个常被忽视的安全反向问题：基础镜像是"固定快照"，如果它停更、或你用了过老的基础镜像，里面可能带着早期漏洞。所以镜像优化不是"只减体积"，还要同时考虑"能用什么基础镜像、版本是否在维护、漏洞有没有定期扫"。常配合的实践是用镜像扫描（如 trivy 这类工具）定期查镜像漏洞，并让基础镜像版本可跟进——别为一个"小的心疼"把基础镜像锁死在早已不维护的版本上。
# 用 trivy 扫镜像漏洞（示例，需先安装）
# trivy image your-app:latest
# 关注基础镜像与运行依赖的 CVE，决策是否升级基镜版本
把边界想清：多阶段构建与瘦身优化的是"镜像构建方式"本身，但不能替你解决"应用正确性"与"依赖安全"——镜像再小，代码有 bug 依旧出错，依赖有了 CVE 还得升。健康的理解是"小 + 快 + 可更新 + 扫出漏洞能跟进"四件事一起抓，而不是只盯着大小。把基础镜像锁在"维护中"的版本、定期扫、保持可升级路径，你的精简镜像才会又瘦又稳又安全地长期用它。
结语
Docker 多阶段构建与镜像瘦身的价值，是把"构建环境"和"运行环境"从同一个镜像里剥离：用临时阶段编译、只把成品拷进精简的运行镜像，既让镜像小、又让依赖干净、还提升构建缓存命中率。落地要点：用 `FROM ... AS` 多阶段 + `COPY --from` 只拷产物；配合 alpine/slim 基镜、剔未用依赖、`.dockerignore` 瘦身；把依赖安装层放前、常变源码放后吃满缓存；并以非 root + 只读化运行。边界是"小快之外更要能长期更新"——基础镜像锁在维护版本、定期扫描并保持可升级路径，你的精简镜像才能既小巧又长期安全地承载你的服务。
