Dockerfile多阶段构建：镜像又小又干净

可视化演示

展示Docker多阶段构建流程、镜像体积对比及构建缓存优化策略，直观理解如何构建又小又干净的生产镜像。

镜像膨胀根源

回到中央厨房。一份三明治只需要面包、生菜、鸡胸肉，但你打开外卖箱，发现里面还塞着整套刀具、平底锅、半袋土豆、三桶酱料和昨天的厨余垃圾。这正是传统单阶段 Dockerfile 的日常：为了让一个很小的服务跑起来，以 ubuntu 为基础镜像，apt-get install 装编译器，npm install 拉全部依赖，最后连源码和缓存一起塞进镜像。

为什么这些杂物甩不掉？因为 Docker 镜像不是一块硬盘快照，而是一层一层叠加的只读层。每一条 RUN、COPY、ADD 都会生成一个新层，文件被添加到新层里。你在后面的层里执行 rm -rf，旧层中的文件不会真正消失，只是被新层标记为“删除”；只要有人提取旧层，文件立刻能回来。所以“装完再删”这条路被 Docker 层模型堵死了。

所以镜像膨胀的本质，是把备餐间的一切都装进了保温盒。要想外卖箱又轻又干净，不是往盒子里补一层“垃圾盖”，而是干脆不把厨房带出去——这正是下一节多阶段构建要解决的事。

多阶段构建原理

中央厨房做事讲分工：备餐间负责切、煮、炖，出餐台只管把成品装进保温盒。多阶段构建用多个 FROM 模拟这个分工。第一个 FROM 是备餐间，第二个 FROM 是出餐台，两者之间只隔一个小窗口。

窗口的学名是 COPY --from=阶段名。只要在某个阶段用 AS builder 命名，后续阶段就能从那个阶段里精确拷贝文件。最终镜像由最后一个阶段决定，前面阶段即使装了几百兆工具，也不会被“带出厨房”。

上面的例子只有两个阶段：builder 阶段用 Go 工具链编译出 server；最终阶段从 scratch 空镜像开始，只做一次 COPY，把 server 放进来。整个保温盒里只有一个可执行文件。

可以看到，多阶段构建不是“删掉不需要的层”，而是“从未把不需要的层装进最终镜像”。备餐间还在仓库里，但外卖箱里只有三明治。

FROM golang:1.21 AS builderWORKDIR /appCOPY . .RUN go build -o server . FROM scratchCOPY --from=builder /app/server /serverENTRYPOINT ["/server"]

builder模式

说回中央厨房，你会专门给招牌菜配一间“备餐间”：里面有商用烤箱、搅拌机、喷枪，工人可以放飞自我。这就是 builder 模式的名字来源——第一个阶段被命名为 builder，专门负责构建产物。

builder 模式的思想是：构建阶段想用多大镜像都行，要能编译、能跑测试、能生成二进制；运行阶段则回到最简单的基础镜像，只保留可执行文件和必要的运行库。对于 Go、Rust 这类静态编译语言，最终阶段可以完全没有 shell、包管理器、编译器。

如果程序是 C 写的，依赖了动态库，别怕：在构建阶段用 ldd 列出 .so 文件，再在 COPY --from 中把这些库一并放到 lib 目录。这一步相当于把酱料、配菜单独装进便当盒的小格子，而不是连整个酱料桶搬上车。

builder 模式是使用最广的多阶段构建套路：备餐间再乱，出餐盒永远干净。

基础镜像优化

给外卖选盒子：有人用厚重的不锈钢饭盒，有人用轻便纸盒，还有人用一片荷叶把饭团一包。Docker 里也有这样的选择——基础镜像就是你的“盒子”。

scratch 是真正的空镜像，里面连 /bin/sh 都没有，体积为 0，适合静态二进制；alpine 基于 musl libc，完整基础镜像约 5MB，适合大多数可静态链接或 musl 兼容的程序；distroless 是 Google 提供的一组镜像，包含 Java、Python 等运行时，但没有 shell 和包管理器，安全和体积兼顾。选盒原则：够用就好，不要贪大。

选对盒子，重量从“一箱厨具”降到“一片荷叶”。多阶段构建的最后一步，常常就是在这些轻量基础镜像上完成的。

上下文瘦身

备餐间要开工，先把今天用不上的食材、旧菜单、废纸箱挡在后门外。.dockerignore 就是这个后门门卫。

docker build 启动时，Docker 客户端会把当前目录整个打成 context 发给 daemon。如果目录里有 .git、node_modules、dist、__pycache__、.env，它们都会坐进这趟“进货卡车”。不仅上传慢，一旦 Dockerfile 里写了 COPY . .，这些文件还会被原样装进备餐间，甚至进入最终镜像。

在项目根目录放一个 .dockerignore，用 .gitignore 的语法排除目录和文件。注意：它排除的是构建上下文，不是自动减基础镜像；如果显式 COPY 一个被忽略的文件，构建会直接报错——这反而是保护机制。

门卫挡掉的不是菜，而是所有不该进后厨的东西。少传一个 .git，可能比后续所有瘦身技巧更立竿见影。

构建缓存优化

老汤店不会每天从洗锅开始熬高汤：只要汤底配方不变，昨天的老汤直接接着用。Docker 的层缓存，就像那锅老汤。

Docker 执行某条指令前，会检查指令文本和涉及的上下文文件是否与上次构建一致；如果一致，就直接复用缓存层，不再重新执行。为了喝到老汤，要把不常变的步骤放前面：先 COPY go.mod go.sum，再 RUN go mod download，最后 COPY . .。源码一改，前面的依赖层仍然命中。

如果反过来把 COPY . . 放最前面，任何源码变化都会让后面所有 RUN 全部重跑，缓存几乎全部失效。较新版本的 Docker 还支持 RUN --mount=type=cache，可以把 apt、pip 的下载目录挂到缓存卷，反复构建更快。

高汤前置、炉火不熄，便当出餐自然快。这也是为什么依赖与代码的顺序，常常比镜像体积数字更能影响工程师的幸福感。

镜像安全扫描

外卖盒封口前，质检员要过一道安检：食材有没有临期，包装有没有破损，盒子里有没有混入钢针。镜像安全扫描就是 Docker 世界的质检员。

扫描工具 Trivy、Grype 会把镜像每一层里的软件包、二进制文件与 CVE 漏洞库比对，给出严重等级。镜像越小、包越少，扫描面越小；这正是多阶段构建顺带带来的安全红利——没有编译器，就没有编译器漏洞；没有 shell，攻击者就没法轻易交互。

在 CI 中可以让扫描成为门禁：trivy image --exit-code 1 --severity HIGH --ignore-unfixed your-image，一旦发现高危漏洞就让流水线失败。还要切记：不要把数据库密码、API Key 写进 ENV 或 RUN 命令，镜像历史会留下痕迹。

安检通过，便当才会被递出窗外；扫不出高危，不只是“更安全”，也是让团队睡得着觉的硬指标。

实践与踩坑

会做便当不代表每次都能完美出餐。现实中，多阶段构建也有几个反复出现的翻车现场，就像把外卖小票和家里钥匙一起塞进了保温盒。

先讲应该怎么做：把最不容易变的 COPY 和 RUN 放前面；单条 RUN 里顺便清理 apt/pip 缓存；需要动态库时就 ldd 后精确拷贝 .so；所有阶段都用 AS 起清晰的名字，避免搞混。

再讲常踩的坑：一是以为 rm -rf /var/cache 能减镜像，其实旧层还在；二是最终阶段仍用 ubuntu 这种大镜像，前功尽弃；三是把密钥写进 ENV，任何人都能拉取镜像历史看到；四是阶段名拼错或漏掉 --from，构建直接失败。多阶段构建不是银弹，它是帮你把“必要文件、工具、临时文件、密钥”四者分开的手术刀。

一次成功的出餐，是把对的菜装进对的盒子，再通过对的窗口递出去。愿你下一次 docker build，也能收获一只轻巧、干净、安心的保温盒。

AI 应用场景

Python 演示

#!/usr/bin/env python3# -*- coding: utf-8 -*-"""Simulate image size for single-stage vs multi-stage Dockerfile."""  class Layer:    def __init__(self, label, delta_mb):        self.label = label        self.delta_mb = delta_mb  def single_stage(base_mb, layers):    total = base_mb    for layer in layers:        total += layer.delta_mb    return total  def multi_stage(runtime_base_mb, artifact_mb, build_layers):    temp_size = runtime_base_mb + sum(l.delta_mb for l in build_layers)    # temp_size is not part of the final image    return artifact_mb  BUILD_LAYERS = [    Layer("COPY source", 20),    Layer("apt-get install gcc", 420),    Layer("go mod download", 310),    Layer("go build", 16),]RUNTIME_BASE_MB = 0  # scratchARTIFACT_MB = 9  def main():    single = single_stage(72, BUILD_LAYERS)    multi = multi_stage(RUNTIME_BASE_MB, ARTIFACT_MB, BUILD_LAYERS)    print("single-stage image: {} MB".format(single))    print("multi-stage image: {} MB".format(multi))    saved = (1 - multi / single) * 100    print("size saved: {:.1f}%".format(saved))  if __name__ == "__main__":    main()

1. class Layer把 Dockerfile 中每一条会生成镜像层的指令建模为一个对象。
2. def single_stage单阶段构建把所有层体积依次累加，对应“把厨房也装进外卖箱”。
3. def multi_stage多阶段构建只返回运行基础镜像与产物体积，构建阶段层被丢弃。
4. BUILD_LAYERS用几条典型指令表示编译器、依赖下载和编译产物。
5. RUNTIME_BASE_MB = 00 表示 scratch 空基础镜像。
6. saved = (1 - multi / single) * 100计算多阶段相对单阶段节省的体积百分比。
7. if __name__ == "__main__"保证脚本可以直接运行，也方便被其他模块导入。

常见误区

面试题