Docker多阶段构建实战：从原理到镜像瘦身与缓存优化

我第一次用 Docker 多阶段构建时，其实不太理解它和普通 Dockerfile 有什么区别，就是照着同事的写法复制了一个FROM ... AS build就完事了。后来有次帮团队排查一个线上镜像，体积居然有 900MB，点开docker history一看，里面躺着 npm、gcc、Python 源码，那一刻我才认真琢磨：“构建用的东西，为什么全留在运行镜像里了？”

后来我在实际项目里把前端 Vite 构建、后端 Go 编译和 Spring Boot 打包都改成了多阶段构建，才真正理解这个特性的价值。它解决的不只是“镜像小一点”，而是把“构建环境”和“运行环境”彻底分离，既保证了交付物是干净的、最小化的，也保留了构建过程的完整性与可复现性。

这篇文章我会先拆解多阶段构建的运行机制，再给两个可以直接抄的 Dockerfile 实践案例，然后聊聊 BuildKit 缓存、ARG/ENV 这类进阶用法，最后把我在踩坑过程中总结的常见问题写出来。不管你是刚学 Docker 的开发，还是正在给团队优化部署流程的运维或 DevOps，这篇都可以直接拿去当参考。

1. 多阶段构建到底解决了什么问题：从“一个镜像什么都塞”讲起

1.1 传统单阶段构建的三大痛点

我见过太多项目用一个FROM node:20或者FROM golang:1.22从头写到尾，所有事情都在一个阶段里完成。这种写法本身没错，跑起来也正常，但随着项目变大，问题会逐渐暴露出来。

第一个问题是镜像体积失控。每个项目都有构建期依赖，比如前端 node_modules 动辄几百 MB 到 1GB，后端 Maven、Gradle 会把整个依赖树拉进镜像。如果构建完直接把这些中间产物留在镜像里，发布到仓库、拉到每台服务器都是实打实的资源和时间消耗。我印象很深的一次是某个微服务镜像 900MB，里面除了编译产物，还有完整的工具链和测试文件，每次部署光拉镜像就要等很久，扩缩容时并发拉取更是直接打满带宽。

第二个问题是安全风险。构建镜像里会有源码、编译工具、调试器，甚至可能包含构建时注入的敏感信息。一旦镜像被推送到公开仓库或者被内部人员误分享出去，攻击者拿到的不只是运行结果，而是整个应用的家底。多阶段构建可以把这些中间内容彻底隔离在最终镜像之外，攻击面一下就小了很多。

第三个问题是构建环境和运行环境混淆。一个镜像同时承担“构建”和“运行”两种职责，会让运行环境难以精简，也难以升级。想换 Node 版本、Go 版本或者底层的 glibc 版本时，你面对的不是一个单纯的运行环境，而是一堆彼此关联的构建依赖，升级风险会成倍增加。

我觉得可以打个比方：传统单阶段构建就像房子装修完之后，不仅住了进去，还把装修队的工具箱、油漆桶、备用瓷砖全堆在客厅里。平时用着没什么问题，时间长了占地方、落灰、不好清理，更麻烦的是你不知道哪些东西能扔、哪些东西以后还要用。

还有一个隐蔽的坑在于，Docker 镜像是由只读层组成的。即使你在 Dockerfile 里执行RUN rm -rf node_modules，文件依然留在下一层里，镜像体积并不会真正变小。删除操作只能新增一个标记层，无法抹掉历史。所以单阶段构建里再怎么“收拾现场”，最终镜像依然很胖。

1.2 多阶段构建的核心机制：stage、FROM、COPY --from 是怎么组合的

理解了上面的痛点，再看多阶段构建就顺理成章了。它的核心机制特别简单：一个 Dockerfile 里可以有多个FROM指令，每个FROM开启一个新的构建阶段，最后 Docker 只保留最后一个阶段作为最终镜像。

下面是一个最基础的多阶段构建骨架：

# 阶段1：负责构建 FROM golang:1.22-alpine AS build-stage WORKDIR /src COPY . . RUN go build -o /app/server . # 阶段2：负责运行 FROM alpine:3.20 AS runtime-stage COPY --from=build-stage /app/server /server ENTRYPOINT ["/server"]

关键点在于AS关键字给阶段起名，以及COPY --from=build-stage可以跨阶段复制文件。这种机制带来的效果和“在同一个阶段里删文件”有本质区别：中间阶段的内容根本没有被引用到最终镜像的文件系统里，所以不会被打包进镜像。它不是“删除”，而是“不生成”。

有人可能好奇，既然中间阶段不进入最终镜像，为什么构建速度还很快？因为 Docker 会把已经构建过的中间阶段缓存在本地构建缓存里。只要阶段的输入没有变化，后续重新构建时就会直接复用缓存，不需要重新编译。

1.3 哪些项目收益最大

多阶段构建不是银弹，但以下几类项目收益会特别明显：

• 编译型语言项目，比如 Go、Java、C++，工具链体积通常很大。
• 前端项目，构建完的 dist 静态文件很小，但 node_modules 很重。
• Python 项目，如果涉及编译扩展、私有依赖，也可以避免把编译器塞进运行镜像。
• 任何需要“构建工具链 + 精简运行环境”分离的场景。

一句话总结：只要你的应用在构建时需要的东西和运行时需要的东西不一样，就值得用多阶段构建。

2. 两个可以直接抄的实战案例：前端静态站点与后端服务

2.1 案例A：Node.js 前端打包后交给 Nginx 托管

先说最常见的场景：一个 Vue 或 React 前端项目，用 Vite 或 Webpack 构建，最终产物是一堆静态文件，需要一个 Web 服务器托管。

最粗暴的写法是直接把整个项目塞进 node 镜像，然后用 node 起一个静态服务器。这样做不是不行，但镜像至少 1GB，而且 node_modules 和源码全暴露在运行环境里。稍微好一点的写法是用 Node 镜像构建，然后把 dist 目录复制到一个干净的 Nginx 镜像里，这正是多阶段构建的标准姿势。

下面是一个可以直接落地的 Dockerfile：

# 阶段1：构建静态资源 FROM node:20-slim AS build-stage WORKDIR /app # 先复制依赖清单文件，再安装依赖，这一步能利用 Docker 缓存 COPY package.json package-lock.json ./ RUN npm ci --no-audit --no-fund # 复制源码并构建 COPY . . ARG VITE_API_BASE=/api RUN npm run build # 阶段2：运行时，使用 Nginx 镜像 FROM nginx:1.25-alpine AS runtime-stage COPY --from=build-stage /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]

这个 Dockerfile 有几个细节值得注意。

第一，COPY package.json package-lock.json ./放在COPY . .前面，目的是让依赖安装这层尽可能命中 Docker 缓存。如果你先复制全部源码，那么只要源码里任何一个文件有变动，后面所有层都会重新执行，npm ci也会重新跑一遍，非常浪费时间。

第二，ARG VITE_API_BASE=/api是构建期变量。Vite 在构建时会读取以VITE_开头的环境变量，把它作为接口地址写进产物里。如果项目里用不到，删掉即可，但很多真实项目确实会在打包时注入这类配置，所以我把这个例子保留下来。

第三，SPA 项目通常需要配置 Nginx 的 try_files 规则，否则刷新某个前端路由时会出现 404。我把常用的 nginx.conf 也贴出来：

server { listen 80; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } }

我实测过一个简单的 Vite 前端项目，不采用多阶段构建时，直接用FROM node:20-slim加npm run preview起服务，镜像体积大概在 1.1GB 左右。改成上面的多阶段写法后，最终镜像只有 40 多 MB——因为 Nginx 的 Alpine 基础镜像本身只有二十几 MB，dist 目录可能只有十几 MB。体积差距肉眼可见。

2.2 案例B：Go 程序构建后放进 scratch 运行

Go 项目可以说是多阶段构建的最佳实践选手，因为 Go 可以编译出完全静态的二进制文件，最终镜像甚至可以直接用scratch——一个空的、没有任何文件的基础镜像。

先看 Dockerfile：

# 阶段1：编译 FROM golang:1.22-alpine AS build-stage RUN apk add --no-cache ca-certificates WORKDIR /src COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server . # 阶段2：运行 FROM scratch AS runtime-stage COPY --from=build-stage /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ COPY --from=build-stage /app/server /server EXPOSE 8080 ENTRYPOINT ["/server"]

这里有几个参数的含义需要展开讲。

CGO_ENABLED=0表示不使用 CGO，让 Go 生成完全静态的二进制文件。如果你的代码依赖了 C 库，比如某些数据库驱动，这个开关会导致编译失败，这种情况下不能关。但大多数 HTTP 服务和业务后台都可以直接关掉，换来的是“扔到哪个 Linux 容器里都能跑”的独立性。

GOOS=linux明确指定目标平台。如果你在 Mac 上交叉编译，不设这个参数的话，生成的是 Darwin 平台的二进制，放进 Linux 容器就会报exec format error。

-ldflags="-s -w"的作用是去除二进制文件中的调试信息和符号表，能把体积再压掉一些。对于一个简单的 Go HTTP 服务，编译出来的二进制可能在 10MB 左右，最终镜像体积就是“二进制大小 + 证书文件大小”，可能只有十几 MB。如果忽略链路追踪等依赖，甚至能压到个位数 MB。

ca-certificates这一步很多人容易忽略。scratch镜像连 CA 证书都没有，如果你的服务需要访问外部 HTTPS 接口，比如调用第三方 API，运行时会直接报证书校验失败。所以在构建阶段用 Alpine 安装证书，再通过COPY --from复制到最终镜像里，这是我在生产环境经常用到的做法。

如果你的二进制没有完全静态编译，而是动态链接了 C 库，那么scratch是不能用的，必须选用与编译器相同 C 库生态的运行镜像。这个问题会在第 4 章专门讲。

2.3 为什么案例都选择“构建阶段 + 运行阶段”这种两步结构

你会发现不管是前端、后端还是其他语言，核心思路都是一样的：先用一个资源充足、工具链完整的阶段负责所有繁重的构建工作，再挑一个干净的镜像作为最终交付环境，只复制产物过去。

这种结构本质上是对“构建产物边界”的强制约束。开发阶段你需要编译器、调试器、依赖管理器，这些是开发体验的一部分，但不应该成为生产交付的一部分。两步结构让这个边界在 Dockerfile 里就清清楚楚：构建阶段是工厂，运行阶段是展厅，工厂能把东西做好，但不需要把整条生产线搬进展厅。

很多人也在用 Docker 安装 MySQL、Redis、GitLab 这类现成镜像，那些是别人写好的“运行型镜像”，已经提前完成了构建和运行的分离。多阶段构建则是在开发你自己的应用镜像时，把同样的工程思想落到你的 Dockerfile 里。

3. 进阶技巧：缓存、参数与多阶段构建组合

3.1 用 BuildKit 让多阶段构建快起来：cache mount 与并发特性

前面几版 Dockerfile 已经利用了最基本的层缓存机制：只要某层指令没有变化，就会复用缓存。但在真实项目里，依赖安装通常是整个构建过程中最耗时的一步，尤其是 npm、pip、apt 这类包管理工具，每次都重新下载全套依赖，时间成本非常高。

解决这个问题需要用到 BuildKit。新版本 Docker 默认开启了 BuildKit，老版本或某些 CI 环境需要手动设置DOCKER_BUILDKIT=1。BuildKit 有两个特性对多阶段构建特别有用：一是可以并发执行无依赖关系的阶段，二是支持RUN --mount=type=cache把指定的目录挂载为持久化缓存。

举个例子，前端构建中的 npm 依赖缓存可以这样写：

RUN --mount=type=cache,target=/root/.npm \ npm ci --no-audit --no-fund

--mount=type=cache会把/root/.npm这个目录挂载成一个跨构建的缓存卷。当package-lock.json没有变化时，依赖包可以直接从缓存里读取，安装几乎秒过。重要的是，这个缓存目录不会被打进镜像层里，它存在于构建机的磁盘上，只服务于构建过程。

同样的思路适用于 Go 模块缓存：

RUN --mount=type=cache,target=/go/pkg/mod \ --mount=type=cache,target=/root/.cache/go-build \ go mod download && go build -o /app/server .

我在 CI 里实测过，加不加 cache mount，同样的 Go 项目构建时间可以从一两分钟降到十几秒。改动成本很低，收益却非常明显。

不过要提醒一句：cache mount 和常规的层缓存是两个独立的缓存机制。层缓存判断的是 Dockerfile 指令是否变化，cache mount 判断的是缓存目录内容是否还有效。两者配合使用效果最好，但也别指望 cache mount 解决所有问题。如果 Dockerfile 第一步就是COPY . .，那么源码一变，后续所有层都要重建，cache mount 也救不回来。

还有个小细节：如果你的 Docker 版本比较旧，使用--mount语法时可能会报未知指令。这时可以在 Dockerfile 第一行加上# syntax=docker/dockerfile:1.4来指定新版解析器，或者在升级 Docker 之后再继续。

3.2 ARG、ENV 与阶段变量隔离

在编写多阶段 Dockerfile 时，ARG和ENV的混淆经常造成不必要的烦恼。

ARG是构建期变量，只在docker build过程中有效。ENV是运行期环境变量，会写入最终镜像，容器启动时自动生效。在多阶段构建里，每个FROM都会重置ARG，也就是说你在阶段 1 声明的ARG VERSION，在阶段 2 里是不存在的，需要重新声明。

看一个例子：

FROM golang:1.22-alpine AS build-stage ARG VERSION RUN go build -ldflags="-X main.version=$VERSION" -o /app/server . FROM scratch AS runtime-stage ARG VERSION ENV APP_VERSION=$VERSION COPY --from=build-stage /app/server /server

这里阶段 1 用ARG VERSION参与编译，阶段 2 又声明了一次ARG VERSION，然后通过ENV把它写进最终镜像。如果不加第二次ARG VERSION，阶段 2 里的变量就是空的，镜像里的APP_VERSION也会是空值。

构建时通过--build-arg传参：

docker build --build-arg VERSION=1.2.3 -t myapp:1.2.3 .

有个安全红线必须守：不要用ARG或ENV传递任何敏感信息，比如密码、Token、私钥。ENV会直接写入镜像的配置信息，任何人只要docker inspect就能看到明文；ARG稍微好一点，但也会记录在docker history里。敏感信息应该用 Docker 的 secret 机制或者运行时注入。

3.3 用多阶段构建做“工具镜像”和“测试镜像”

多阶段构建不只是用来压缩体积，另一种很实用的模式是把它当作一个流程控制工具。

比如在正式构建前先跑 lint 和测试，测试不通过就不产出最终镜像：

FROM node:20-slim AS test-stage WORKDIR /workspace COPY package.json package-lock.json ./ RUN npm ci --no-audit --no-fund COPY . . RUN npm run lint && npm run test FROM nginx:1.25-alpine AS runtime-stage COPY --from=build-stage /app/dist /usr/share/nginx/html

当你在 CI 里执行docker build -t myapp:latest .时，Docker 会先执行test-stage中的指令。如果 lint 或测试失败，构建直接中断，最终镜像不会生成。这比“先构建、再推到仓库、部署之后才发现测试挂掉”的流程要可靠得多。

也可以用--target参数只构建某个阶段，方便本地调试：

docker build --target=test-stage -t myapp:test . docker build --target=build-stage -t myapp:dev .

这种用法在现场排错时尤其方便。比如我想单独看看前端 dist 文件长什么样，但不想等后面把镜像一层层构建完，可以直接指定--target=build-stage。

还有一种模式是“调试工具镜像”。生产环境为了安全会用 scratch 或 distroless 这类极简镜像，里面连 shell 都没有，没法进容器执行curl、dig这些命令。如果哪天线上网络或 DNS 出了问题，排查起来确实麻烦。我会额外维护一个debug阶段，在最终镜像基础上塞进常用的调试工具，只在需要排查时构建一份 debug 镜像：

FROM nginx:1.25-alpine AS debug-stage RUN apk add --no-cache curl busybox-extras COPY --from=build-stage /app/dist /usr/share/nginx/html

这样既保证了默认镜像的最小化，不至于让每一个线上容器都带上多余工具，又能在关键时刻快速获得一个具备排查能力的镜像。

4. 常见失败与排查实录：我踩过的几个多阶段构建的坑

4.1 COPY --from 找不到阶段：命名和大小写问题

我第一次用多阶段构建时就遇到了这个报错：

invalid from flag value build-stage: pull access denied for build-stage

报错内容虽然长，但核心问题是 Docker 把build-stage当作一个镜像名去拉取了，这说明它并没有识别出这是一个阶段名。最常见的原因是FROM和后面的COPY --from中阶段名大小写不一致，或者拼写错误。

排查思路很直接：先检查每个阶段名是否一致，特别注意大小写。如果用的是数字索引COPY --from=0，也不用慌，但数字索引的可读性很差，一旦调整阶段顺序就容易出错。我建议务必给每个阶段起一个有意义的名字，比如build-stage、test-stage、runtime-stage，时间久了你会发现这比依赖索引值可靠得多。

还有一点值得留意：当--from的内容不是某个已知阶段名时，Docker 会把它当作外部镜像去拉取。所以报错不一定是阶段名写错，也有可能是阶段名忘记加AS关键字，或者基础镜像名本身写错了。

4.2 文件权限与属主问题：复制后不能启动

有次帮一个同事排查镜像，构建成功、镜像也正常，但容器跑起来就报permission denied。查了半天发现是最终阶段没有给二进制文件加执行权限。

COPY --from复制文件时会保留文件原有的权限位。如果源阶段生成的二进制文件没有执行权限，复制过来也没有。解决办法有两种，一是在构建阶段编译完成后显式RUN chmod +x /app/server，二是在复制时用COPY --from=build-stage --chmod=755 /app/server /server，不过--chmod需要新版 BuildKit 支持，更稳妥的写法还是先chmod再复制。

如果是非 root 用户运行容器，还要注意属主问题。Nginx 官方镜像默认以 root 启动，但很多安全配置会使用非 root 用户。把构建产物复制到运行镜像时，用--chown调整属主：

COPY --chown=1000:1000 --from=build-stage /app/dist /usr/share/nginx/html

如果属主不对，容器内用户可能无法读取文件，启动时表现得很奇怪，比如页面 403 或者日志里突然出现一堆Permission denied。

有一种现象特别容易误判是权限问题：二进制在容器启动时报exec format error。这个错误通常不是权限，而是架构不匹配，比如在 x86 的构建机上编译了 arm64 的二进制，或者反过来。排查时先执行file /server看二进制架构，确认和基础镜像的架构一致。

4.3 libc 不匹配：alpine 构建、ubuntu 运行的崩溃

这个坑属于“你一旦遇到就很难忘掉”的类型。

假设你在golang:1.22-alpine阶段编译了一个没有设置CGO_ENABLED=0的程序，而这个程序又通过 SQLite 驱动这类需要 CGO 的库使用了 C 代码，那么生成的二进制会动态链接到 Alpine 自带的 musl libc。然后你把二进制复制到一个基于 Ubuntu 的运行镜像里，Ubuntu 用的是 glibc。程序启动时找不到合适的动态链接库，直接报错或崩溃。

解决办法有两条路：

第一条路是尽量走静态编译。对于 Go 项目，设置CGO_ENABLED=0可以生成不依赖任何 C 库的纯静态二进制，扔到 scratch、alpine、ubuntu 都能跑。前提是你的代码依赖的库都能在 CGO 关闭的情况下编译通过。

第二条路是统一 libc 生态。如果项目必须用 CGO，那么构建阶段和运行阶段最好使用同一种基础镜像体系。要么都用 Ubuntu/Debian 系列，要么都用 Alpine 系列，不要混合使用。很多项目直接用golang:1.22（Debian 基础镜像）构建，运行阶段用ubuntu，这一对组合是安全的。

同样的道理适用于任何依赖原生扩展的编译型项目。判断一个二进制是不是静态编译，Linux 环境可以用ldd命令查看动态链接依赖，如果输出一堆not found，那基本就是动态链接且缺少 C 库。

4.4 .dockerignore 与构建上下文过大

某个项目构建时尤其慢，日志里出现一行：

Sending build context to Docker daemon 1.2GB

一看就知道.dockerignore没写或者没写好。构建上下文指的是发送给 Docker daemon 的所有文件，COPY . .会把整个上下文里的内容复制进镜像对应层。如果 node_modules、dist、.git 这些动辄几百 MB 的目录都混在上下文里，每次构建都要先把它们从客户端传过去，然后 Docker 还得逐个处理。

我在每个项目里都会维护一份基础.dockerignore：

node_modules dist .git .gitignore Dockerfile .dockerignore *.log

有个容易忽略的点：.dockerignore影响的是“发送给 Docker daemon 的构建上下文大小”，以及COPY . .会复制哪些文件，但不会影响 COPY 阶段之外被手动指明的文件。所以配合多阶段构建使用，效果才是叠加的——上下文小了，复制内容少了，最终镜像也更干净。

4.5 构建缓存失效：为什么改了源码导致整个重新构建

有同学问过我：我改了main.go一行代码，为什么前面的go mod download又重新跑了一遍？

原因是 Docker 的缓存判定是按指令级变化的。当某条指令的输入发生变化，这条指令开始的所有后续缓存都会失效。如果你把COPY . .放在RUN go mod download之前，那么只要源码里有任何一个文件变化，COPY层的缓存就失效了，后面所有层只能从头执行。

正确的笑缓存姿势是：先复制只依赖清单文件，比如go.mod、go.sum、package.json、package-lock.json，再执行依赖下载。之后才复制完整的源码目录。这样源码改动只会影响从COPY . .开始的层，依赖安装层可以继续命中缓存。

COPY go.mod go.sum ./ RUN go mod download COPY . . RUN go build -o /app/server .

如果项目里存在某些构建工具必须读取源码才能解析依赖，比如少数动态生成的依赖清单，那缓存确实没办法完全命中，只能靠 cache mount 来缓解。总的原则是：把变化频率越低的文件，越往前放。

4.6 常见问题速查表

5. 实践建议：把多阶段构建嵌入团队工程流程

5.1 开发者本机、CI 和镜像仓库分别关注什么

多阶段构建并不是只在docker build那一步有用，它会影响整个交付链路，所以每个环节的关注点不太一样。

开发者本机，最常用的不是一味docker build -t myapp:latest .，而是用--target配合临时标签做单阶段调试。比如我在本地开发时经常执行docker build --target=build-stage -t myapp:dev .，这样能快速验证构建阶段是否正常，避免为了看前端 dist 产物还得把后面 Nginx 阶段也跑完。构建完还可以用docker run --rm -it myapp:dev sh进入容器确认中间产物。

CI 环境里，重点关注两件事：构建时间和构建缓存。BuildKit 的 cache mount 是首选优化手段，没有之一。CI 机器如果支持外部缓存，可以考虑把 BuildKit 缓存持久化到远程存储，这样本地构建机、开发机、CI 机器都能复用同一份依赖缓存，效果比单机缓存更好。

镜像仓库这边，回答的是“某个镜像具体是哪个代码版本构建出来的”这个问题。发布镜像时，我习惯同时打上 commit 短哈希、版本号和带环境前缀的标签，比如myapp:1.2.3和myapp:1.2.3-abcdef12，避免所有人都去打latest标签。线上环境用latest是一个随时间推移一定会踩坑的习惯，因为没法快速确认当前跑的是哪一次构建。

构建完成后，可以用docker history myapp:1.2.3快速查看镜像的历史层，确认最终镜像里到底装了哪些依赖——这一步能很直观地看出多阶段构建是否真正起了作用。

5.2 镜像体积之外：安全扫描与最小依赖

多阶段构建在安全层面的贡献，很多人容易忽略。因为最终镜像里没有了编译器、调试器、源码、构建依赖，攻击者在容器里可以利用的攻击面会小很多。即使应用被攻破，镜像里也没有顺手可用的工具链、包管理器和额外的系统组件。

在此基础上再进一步，可以使用 distroless 或 scratch 这类极简镜像。它们连 shell 都没有，攻击者拿到一个 shell 后甚至找不到/bin/bash来执行命令，这是降低横向扩散风险的一种手段。

当然，最小化不能牺牲可观测性。线上确实需要 debug 时，前面提到的 debug 阶段就可以派上用场——默认构建最小的生产镜像，需要排查时再临时构建带调试工具的镜像。不少团队把这种模式写成 CI 的一个选项，我觉得很值得借鉴。

另外，多阶段构建只是减少了“最后一公里”的风险，基础镜像本身的漏洞依然要靠安全扫描来发现。可以在 CI 里集成 Trivy 或类似镜像扫描工具，定期扫描仓库里的镜像，重点看基础镜像版本是否有新增漏洞。基础镜像不是越新越好，但完全不更新的基础镜像隐患更大。

5.3 多阶段构建不能替代哪些实践

多阶段构建解决的是镜像尺度和构建链分离的问题，但它不是银弹，有些事它做不了。

首先，它不能替代自动化测试。测试应该存在于构建流程的早期阶段，比如第 3 章里提到的 test-stage 模式，而不是把测试脚本扔进最终镜像里，等到运行时才执行。

其次，它不能替代代码审查和依赖治理。镜像再小，如果代码层存在漏洞，攻击面依然存在。多阶段构建只是让交付物更干净，不是让代码更安全。

最后，它不能替代基础镜像的更新和维护。即使使用了 scratch 或 distroless，一旦基础镜像发现严重漏洞，你依然需要重新构建、测试和发布。把“多阶段构建”和“基础镜像版本固定”放在一起做版本管理，会让整个镜像生命周期清晰很多。

我的建议是：把多阶段构建当成 Dockerfile 的默认组织方式，而不是什么高阶技巧。任何一个新的交付型镜像项目，上来就按“build 阶段 + runtime 阶段”的结构去写，中间有测试再加 test 阶段。再配合 BuildKit 缓存和.dockerignore，整个镜像构建和发布的体验会稳定很多。

最后分享一点我个人的体会。真正让我对多阶段构建产生好感的，不是某个具体案例里镜像从几百 MB 缩到了几十 MB，而是团队协作变简单了。以前每个人写的 Dockerfile 风格都不一样，有人喜欢在最后阶段再装一遍编译工具，有人会在运行时去拉代码重新构建，镜像仓库里各种体积和依赖的镜像都有。后来我们约定新项目默认按“build + runtime”两步写，配合--target和 BuildKit 缓存，新同事上手很快，镜像体积和构建时间也有了稳定的改进空间。

如果你现在还在用传统单阶段方式，我建议找一个不太重要的服务先改一版多阶段构建，顺手量一下镜像体积和构建时间，再决定要不要推广。构建运行分离这个思路本身并不复杂，真正有价值的是在一次次实操中形成自己的习惯和预判。希望这篇实践指南，能帮你少踩几个我当年踩过的坑。