我第一次用 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 --frombuild-stage /app/server /server ENTRYPOINT [/server]关键点在于AS关键字给阶段起名以及COPY --frombuild-stage可以跨阶段复制文件。这种机制带来的效果和“在同一个阶段里删文件”有本质区别中间阶段的内容根本没有被引用到最终镜像的文件系统里所以不会被打包进镜像。它不是“删除”而是“不生成”。有人可能好奇既然中间阶段不进入最终镜像为什么构建速度还很快因为 Docker 会把已经构建过的中间阶段缓存在本地构建缓存里。只要阶段的输入没有变化后续重新构建时就会直接复用缓存不需要重新编译。1.3 哪些项目收益最大多阶段构建不是银弹但以下几类项目收益会特别明显编译型语言项目比如 Go、Java、C工具链体积通常很大。前端项目构建完的 dist 静态文件很小但 node_modules 很重。Python 项目如果涉及编译扩展、私有依赖也可以避免把编译器塞进运行镜像。任何需要“构建工具链 精简运行环境”分离的场景。一句话总结只要你的应用在构建时需要的东西和运行时需要的东西不一样就值得用多阶段构建。2. 两个可以直接抄的实战案例前端静态站点与后端服务2.1 案例ANode.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 --frombuild-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 基础镜像本身只有二十几 MBdist 目录可能只有十几 MB。体积差距肉眼可见。2.2 案例BGo 程序构建后放进 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_ENABLED0 GOOSlinux go build -ldflags-s -w -o /app/server . # 阶段2运行 FROM scratch AS runtime-stage COPY --frombuild-stage /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ COPY --frombuild-stage /app/server /server EXPOSE 8080 ENTRYPOINT [/server]这里有几个参数的含义需要展开讲。CGO_ENABLED0表示不使用 CGO让 Go 生成完全静态的二进制文件。如果你的代码依赖了 C 库比如某些数据库驱动这个开关会导致编译失败这种情况下不能关。但大多数 HTTP 服务和业务后台都可以直接关掉换来的是“扔到哪个 Linux 容器里都能跑”的独立性。GOOSlinux明确指定目标平台。如果你在 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_BUILDKIT1。BuildKit 有两个特性对多阶段构建特别有用一是可以并发执行无依赖关系的阶段二是支持RUN --mounttypecache把指定的目录挂载为持久化缓存。举个例子前端构建中的 npm 依赖缓存可以这样写RUN --mounttypecache,target/root/.npm \ npm ci --no-audit --no-fund--mounttypecache会把/root/.npm这个目录挂载成一个跨构建的缓存卷。当package-lock.json没有变化时依赖包可以直接从缓存里读取安装几乎秒过。重要的是这个缓存目录不会被打进镜像层里它存在于构建机的磁盘上只服务于构建过程。同样的思路适用于 Go 模块缓存RUN --mounttypecache,target/go/pkg/mod \ --mounttypecache,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 第一行加上# syntaxdocker/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 --frombuild-stage /app/server /server这里阶段 1 用ARG VERSION参与编译阶段 2 又声明了一次ARG VERSION然后通过ENV把它写进最终镜像。如果不加第二次ARG VERSION阶段 2 里的变量就是空的镜像里的APP_VERSION也会是空值。构建时通过--build-arg传参docker build --build-arg VERSION1.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 --frombuild-stage /app/dist /usr/share/nginx/html当你在 CI 里执行docker build -t myapp:latest .时Docker 会先执行test-stage中的指令。如果 lint 或测试失败构建直接中断最终镜像不会生成。这比“先构建、再推到仓库、部署之后才发现测试挂掉”的流程要可靠得多。也可以用--target参数只构建某个阶段方便本地调试docker build --targettest-stage -t myapp:test . docker build --targetbuild-stage -t myapp:dev .这种用法在现场排错时尤其方便。比如我想单独看看前端 dist 文件长什么样但不想等后面把镜像一层层构建完可以直接指定--targetbuild-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 --frombuild-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 --from0也不用慌但数字索引的可读性很差一旦调整阶段顺序就容易出错。我建议务必给每个阶段起一个有意义的名字比如build-stage、test-stage、runtime-stage时间久了你会发现这比依赖索引值可靠得多。还有一点值得留意当--from的内容不是某个已知阶段名时Docker 会把它当作外部镜像去拉取。所以报错不一定是阶段名写错也有可能是阶段名忘记加AS关键字或者基础镜像名本身写错了。4.2 文件权限与属主问题复制后不能启动有次帮一个同事排查镜像构建成功、镜像也正常但容器跑起来就报permission denied。查了半天发现是最终阶段没有给二进制文件加执行权限。COPY --from复制文件时会保留文件原有的权限位。如果源阶段生成的二进制文件没有执行权限复制过来也没有。解决办法有两种一是在构建阶段编译完成后显式RUN chmod x /app/server二是在复制时用COPY --frombuild-stage --chmod755 /app/server /server不过--chmod需要新版 BuildKit 支持更稳妥的写法还是先chmod再复制。如果是非 root 用户运行容器还要注意属主问题。Nginx 官方镜像默认以 root 启动但很多安全配置会使用非 root 用户。把构建产物复制到运行镜像时用--chown调整属主COPY --chown1000:1000 --frombuild-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_ENABLED0的程序而这个程序又通过 SQLite 驱动这类需要 CGO 的库使用了 C 代码那么生成的二进制会动态链接到 Alpine 自带的 musl libc。然后你把二进制复制到一个基于 Ubuntu 的运行镜像里Ubuntu 用的是 glibc。程序启动时找不到合适的动态链接库直接报错或崩溃。解决办法有两条路第一条路是尽量走静态编译。对于 Go 项目设置CGO_ENABLED0可以生成不依赖任何 C 库的纯静态二进制扔到 scratch、alpine、ubuntu 都能跑。前提是你的代码依赖的库都能在 CGO 关闭的情况下编译通过。第二条路是统一 libc 生态。如果项目必须用 CGO那么构建阶段和运行阶段最好使用同一种基础镜像体系。要么都用 Ubuntu/Debian 系列要么都用 Alpine 系列不要混合使用。很多项目直接用golang:1.22Debian 基础镜像构建运行阶段用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 还得逐个处理。我在每个项目里都会维护一份基础.dockerignorenode_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 常见问题速查表现象可能原因解决办法COPY --from 报拉取错误阶段名拼写错误、大小写不一致检查阶段名或改用--from0临时代替容器启动报 permission denied二进制或文件缺少执行权限构建阶段执行chmod x或用--chmod容器启动报 exec format error编译架构和运行镜像架构不一致用file命令确认架构设置GOOS/GOARCH程序启动后崩溃或找不到动态库构建阶段和运行阶段 libc 不匹配关闭 CGO 静态编译或统一 libc 生态构建日志显示 context 巨大缺少.dockerignore补齐.dockerignore排除无用目录改了源码后面所有层重建依赖安装层位于COPY . .之后调整文件复制顺序先复制依赖清单镜像体积没有明显变小仍把大目录或中间产物复制进最终阶段检查最终阶段COPY --from的来源路径阶段 2 读不到阶段 1 的变量ARG 在每个 FROM 后会被重置需要再次声明ARG或用ENV跨阶段传递5. 实践建议把多阶段构建嵌入团队工程流程5.1 开发者本机、CI 和镜像仓库分别关注什么多阶段构建并不是只在docker build那一步有用它会影响整个交付链路所以每个环节的关注点不太一样。开发者本机最常用的不是一味docker build -t myapp:latest .而是用--target配合临时标签做单阶段调试。比如我在本地开发时经常执行docker build --targetbuild-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 缓存新同事上手很快镜像体积和构建时间也有了稳定的改进空间。如果你现在还在用传统单阶段方式我建议找一个不太重要的服务先改一版多阶段构建顺手量一下镜像体积和构建时间再决定要不要推广。构建运行分离这个思路本身并不复杂真正有价值的是在一次次实操中形成自己的习惯和预判。希望这篇实践指南能帮你少踩几个我当年踩过的坑。