3. 传统构建的痛点：单阶段构建导致镜像臃肿的典型场景
在进入多阶段构建实战之前，必须先理解单阶段构建（Single-Stage Build）为何会导致镜像体积失控。单阶段构建将所有操作——从编译环境安装、依赖下载、源码编译到最终产物打包——全部塞进同一个 Dockerfile 指令序列中，最终镜像不仅包含运行所需的二进制文件，还残留了大量构建时工具、缓存文件和调试符号。
核心矛盾：构建环境与运行环境混用。编译工具链、依赖缓存、调试符号等构建期产物被永久打包进镜像，导致镜像体积膨胀 3~10 倍，且增加了攻击面。
3.1 编译工具残留
后端服务（如 Go、Java、C++）在编译阶段需要完整的工具链：编译器、链接器、头文件、构建工具（Maven/Gradle/CMake）。这些工具在运行时完全不需要，但单阶段构建无法将它们剥离。
| 语言/框架 | 典型编译工具 | 工具链体积（约） | 运行时是否需要 |
|---|---|---|---|
| Go | go build、gcc、git | 300~500 MB | 否 |
| Java (Spring Boot) | JDK、Maven/Gradle、maven-repo 缓存 | 600~900 MB | 仅需 JRE（约 200 MB） |
| C++ | g++/clang、cmake、make、静态库 | 800 MB~1.5 GB | 否 |
| Node.js | npm/yarn、node-gyp、C++ 编译链 | 400~700 MB | 仅需 Node.js 运行时 |
典型案例：一个 Spring Boot 项目使用
mvn clean package 构建，单阶段镜像中残留了 Maven 安装包（~150 MB）、本地仓库缓存（~300 MB）、JDK 完整工具链（~400 MB），而最终 JAR 包仅 50 MB。镜像体积从 50 MB 膨胀到 900 MB，膨胀比高达 18 倍。
3.2 依赖缓存残留
包管理器在下载依赖时，会保留本地缓存以加速后续构建。这些缓存文件在单阶段构建中不会被清理，或者清理不彻底，导致镜像层永久保留这些数据。
- Maven/Gradle：
~/.m2/repository或~/.gradle/caches目录，包含所有下载的 JAR 包和插件，体积可达 500 MB~1 GB。 - npm/yarn：
node_modules目录 +~/.npm/_cacache缓存，包含所有依赖源码和二进制包，体积 200~600 MB。 - pip：
~/.cache/pip目录，包含 wheel 包和源码包，体积 100~300 MB。 - apt/apk：包管理器缓存
/var/cache/apt或/var/cache/apk，安装编译依赖后未清理，体积 50~200 MB。
避坑指南：即使你在 Dockerfile 末尾执行
RUN rm -rf /var/cache/apt/*，如果该命令与安装命令不在同一 RUN 层，缓存文件仍然会被保留在上一层镜像中。单阶段构建的层缓存机制让“事后清理”几乎无效。
3.3 调试符号与中间产物残留
编译过程中产生的调试信息（debug symbols）、中间目标文件（.o、.class）、临时文件、测试报告等，在单阶段构建中往往被忽略或无法彻底清除。
| 残留类型 | 来源 | 典型体积 | 安全风险 |
|---|---|---|---|
| 调试符号（DWARF） | Go/C++ 编译默认生成 | 20~100 MB | 暴露源码路径、变量名、行号信息 |
| 中间目标文件 | GCC/Clang 编译产生的 .o 文件 | 50~200 MB | 低（但占用体积） |
| 测试报告/覆盖率 | CI 阶段生成的 HTML/XML 报告 | 10~50 MB | 可能泄露测试数据与内部路径 |
| 符号表（.symtab/.strtab） | ELF 二进制文件默认包含 | 5~30 MB | 暴露函数名、全局变量名 |
安全视角：调试符号不仅增加体积，还会暴露源码结构。攻击者可以通过
strings 命令从二进制中提取出内部函数名、文件路径、日志字符串，辅助漏洞挖掘。生产镜像必须剥离调试符号。
3.4 单阶段构建的层缓存陷阱
Docker 镜像由只读层（Layer）堆叠而成。单阶段构建中，每个 RUN、COPY、ADD 指令都会生成一个新层。即使你在后续层中删除了文件，文件数据仍然存在于前一层中，只是被标记为“已删除”，镜像体积不会减少。
层缓存陷阱演示：
# 错误做法：安装与清理在不同 RUN 层
RUN apt-get update && apt-get install -y build-essential # 层 A：安装工具，体积 +500 MB
RUN rm -rf /var/cache/apt/* # 层 B：标记删除，但层 A 仍保留数据
# 最终镜像体积：500 MB（层 A）+ 0 MB（层 B 仅元数据）= 500 MB，实际运行不需要这些工具正确的做法是将安装与清理合并到同一个 RUN 指令中，或者——更优的方案——使用多阶段构建彻底分离构建环境与运行环境。
关键指标：单阶段构建的镜像中，通常 70%~90% 的内容是构建期产物，真正运行所需的二进制/字节码仅占 10%~30%。多阶段构建的目标就是将这 10%~30% 的“有效载荷”提取出来，丢弃其余 70%~90% 的构建垃圾。
3.5 典型场景体积对比
| 应用类型 | 单阶段镜像体积 | 运行产物体积 | 浪费比例 | 主要浪费来源 |
|---|---|---|---|---|
| Go HTTP 服务 | 1.2 GB | 15 MB | 98.7% | Go SDK、gcc、git、调试符号 |
| Spring Boot 应用 | 950 MB | 180 MB (JRE+JAR) | 81.0% | JDK、Maven、m2 缓存 |
| Node.js Express 应用 | 1.1 GB | 250 MB | 77.3% | node-gyp、C++ 编译链、npm 缓存 |
| Python Flask 应用 | 700 MB | 150 MB | 78.6% | pip 缓存、gcc、Python-dev 头文件 |
生产教训：某团队将 Go 微服务单阶段镜像（1.2 GB）直接推送到生产环境，导致以下后果：
• 镜像拉取时间从 5 秒增加到 45 秒（影响弹性伸缩速度）
• 磁盘占用增加 8 倍（每台宿主机部署 20 个副本，浪费 24 GB）
• 安全扫描发现 47 个高危漏洞（来自残留的 gcc、git 等工具）
• 容器启动后，攻击者可通过残留的 curl/wget 工具进行横向移动
• 镜像拉取时间从 5 秒增加到 45 秒（影响弹性伸缩速度）
• 磁盘占用增加 8 倍（每台宿主机部署 20 个副本，浪费 24 GB）
• 安全扫描发现 47 个高危漏洞（来自残留的 gcc、git 等工具）
• 容器启动后，攻击者可通过残留的 curl/wget 工具进行横向移动