RUN指令导致镜像体积膨胀的根源在于每行生成只读层且无法真正删除上层数据；应合并操作至单行、采用多阶段构建，并选用精简基础镜像及优化参数。
RUN 指令是 Docker 镜像体积膨胀最常见源头——它每执行一次，就固化一个只读层，而删除操作无法抹去上一层已写入的内容。理解它的分层逻辑，本质就是理解“层不可变”和“写时复制”这两个核心规则。
每一行 RUN 都会新增一层
Docker 构建时，RUN 命令的执行结果（如安装的软件、生成的文件、下载的包）会被完整保存为一个新镜像层。哪怕只是 RUN apt-get update 和 RUN apt-get install nginx 两行，也会产生两个独立层；第二层无法覆盖或清除第一层留下的缓存目录。
- 层是只读的，不能被后续层“真正删除”
- 即使你在下一层运行
RUN rm -rf /var/lib/apt/lists/*，上一层的缓存仍物理存在 - 最终镜像大小 = 所有层大小之和，包括已被“掩盖”的冗余数据
合并命令才能真正清理中间产物
把安装、使用、清理放在同一行 RUN 中，确保所有操作发生在同一个层内，避免残留。
- ❌ 错误写法（生成3层，缓存残留）：
RUN apt-get update<br> RUN apt-get install -y curl<br> RUN rm -rf /var/lib/apt/lists/*
- ✅ 正确写法（仅1层，无残留）：
RUN apt-get update && \<br> apt-get install -y curl && \<br> rm -rf /var/lib/apt/lists/*
用多阶段构建彻底剥离构建依赖
编译类项目（Go/Java/Node.js）常因打包工具、源码、中间文件导致镜像臃肿。RUN 在构建阶段产生的大量内容，根本不需要进入最终镜像。
- 第一阶段用完整镜像（如
golang:1.22）执行编译 - 第二阶段切换轻量镜像（如
alpine:3.18），只 COPY 编译好的二进制文件 - 最终镜像里没有 Go 编译器、源码、.go 文件、模块缓存 —— 体积可缩小 90% 以上
配合基础镜像与构建参数进一步压缩
RUN 的效果高度依赖上下文环境。选错基础镜像或忽略构建细节，会让优化事倍功半。
- 优先选用
alpine或debian:slim替代ubuntu:20.04，从源头减少基础层体积（700MB → 5MB） - 启用 BuildKit（
DOCKER_BUILDKIT=1）可提升层复用率，跳过未变更的 RUN 步骤 - 用
--no-install-recommends参数精简 apt 安装，避免带入非必要依赖
