先记住这个答案
在 Dockerfile 中，RUN、COPY、ADD 将实际文件或目录差异保存为新的镜像层，而 ENV、WORKDIR、CMD 等指令只修改镜像配置，不产生文件层。每条指令都可能影响构建缓存，但只有文件层占用额外体积。设计时应合并极少变化的系统依赖 RUN，同时把必然变更的 COPY 放后，从而利用缓存并避免层数膨胀。
- RUN、COPY、ADD 生成文件层
- ENV、CMD 等只写配置不占层空间
- 合并 RUN 能减层但可能破坏缓存
哪些指令真正写入文件系统
RUN 执行命令后，前后文件系统差异会被打包成一个新层；COPY 和 ADD 从构建上下文或外部源导入文件，同样以新层记录。这些层顺序叠加在父层之上，构成镜像的联合文件系统。诸如 ENV、WORKDIR、USER、EXPOSE 等指令只修改镜像配置，记录在元数据中，不产生文件目录变更，因此镜像体积不会因它们而增加。
从构建缓存角度来看，每条指令都会计算缓存键，任何指令本身或其依赖的变化都会使该指令及后续指令的缓存失效，无论是否涉及文件层变更。ENV 等元数据变化同样会使缓存失效，但由于不包含文件内容，失效后的重新执行成本相对低。充分理解这一点，能指导我们决定哪些指令应合并以减层数，哪些指令必须拆分以保持缓存粒度。
合并稳定的系统依赖安装步骤
具体条件：项目基于 node:20-slim，需要安装 git、python3、make 和 g++。若写成三条独立 RUN，修改任一包名都会使后续层失效；若合并为一条 RUN apt-get update && apt-get install -y git python3 make g++ && rm -rf /var/lib/apt/lists/*，则只需一次网络请求，且去除缓存文件减少中间层残留。此时系统依赖极少变化，合并带来的缓存失效风险很低。
实际操作中，把系统安装放在最前，随后 COPY package.json 和 package-lock.json 并执行 RUN npm ci，最后再 COPY 应用代码。这样源码变动不会波及系统层和依赖层，npm ci 因内容固定得以命中缓存。系统安装从不改动，合并值得；npm ci 不合并反而因要利用缓存而保持独立。
何时不宜合并或盲目减层
合并 RUN 主要针对列表式系统包，但若指令依赖前一步 COPY 的文件，合并会扩大失效范围。例如先 COPY 源码再 RUN 构建，源码一变整个构建步骤重跑；若拆开，源码变动仅失效 COPY 和后续 RUN，但若多个源码版本都触发构建，分离能缓存不变的前置层。不当合并会牺牲缓存命中率。
另外 BuildKit 的多 RUN --mount=type=cache 不会把缓存目录写入镜像层，因此不会增加镜像体积，此时无需为了减层而合并 RUN。现代构建器还能自动处理部分内联缓存，强制合并反而降低可读性。若目标只是减小最终镜像体积，应将重点放在多阶段构建，而非单纯压缩层数。
容易答错的地方
- 将 ENV/WORKDIR 也视为文件层
- 部分开发者误以为每条指令都产生一个文件快照层。实际上 ENV、WORKDIR 等只写入镜像配置，docker history 能看到行为，但文件层列表中并不存在这些内容，也不会增加镜像体积。
- 把所有 RUN 合并成一条
- 过去为减少层数而强制合并所有 RUN，导致一旦某一句失效整条重跑。正确做法是按变更频率分层：不变系统包合并，会随代码变化的构建步骤独立，以保持缓存有效性。
面试官还会怎么问？
如何查看镜像每一层的实际命令？
使用 docker history --no-trunc <镜像> 可看到每条 Dockerfile 指令；docker inspect 展示层摘要。历史记录会列出 ENV 等元数据指令，但注意这些不产生文件层。
COPY 与 RUN 都产生层，为什么 COPY 常单独前置？
COPY 的缓存键由源文件内容决定，代码变更会让后续层全部失效。若依赖文件未变，单独 COPY 能保住后续 npm ci 等缓存。把 COPY 与其他操作分离，可让稳定部分复用。
为什么 RUN apt-get update && apt-get install 必须在同一行？
若分开写，update 的层可能被缓存，后续 install 每次都会用旧索引，导致装到的包不是最新或缺失。合并后这两步要么一起执行，要么一起失效，避免逻辑不一致。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。