链式书写命令需合并RUN指令以减少层数、清理中间产物并提升缓存复用率；按变更频率排序指令以最大化缓存命中；配合多阶段构建实现构建与运行环境分离；慎用&&连接符，注意失败退出逻辑。
链式书写命令本身不能单独确保镜像最优化，但它是一个关键操作手段——核心在于**减少层数、清理中间产物、提升缓存复用率**。真正起决定作用的是如何组织这些链式命令，以及它们在整个构建流程中的位置和上下文。
合并 RUN 指令，避免分层残留
Dockerfile 中每条 RUN 都会生成一个新层，未清理的临时文件（如 apt 缓存、下载包、构建中间文件）会永久保留在该层中，即使后续 RUN 删除了它们，体积也不会减少。
- ❌ 错误写法（产生冗余层）：
RUN apt-get update
RUN apt-get install -y curl
RUN apt-get clean && rm -rf /var/lib/apt/lists/* - ✅ 正确写法（单层内完成安装+清理）：
RUN apt-get update && \
apt-get install -y curl && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
这样所有操作都在同一层完成，最终镜像不包含任何缓存或临时文件。
按变更频率排序指令，最大化缓存命中
链式命令要放在“稳定内容之后、易变内容之前”的合理位置。例如：
- 基础依赖（如系统工具、通用库）应尽早安装，并与不常变动的配置合并；
- 应用代码 COPY 应尽量靠后，避免因源码频繁修改导致前面所有层缓存失效；
- 如果 RUN 中包含下载远程资源（如 wget、curl），建议加校验（如 sha256sum）或使用 --no-cache-dir 等参数，防止因网络响应变化导致缓存误判。
配合多阶段构建，让链式命令只在需要的地方生效
链式命令的价值在多阶段构建中被放大：它只作用于当前阶段，且不会污染最终镜像。
- 构建阶段可放心使用复杂链式命令编译、测试、打包；
- 运行阶段仅需一条精简的 COPY --from=builder 和 CMD，完全规避运行时环境臃肿问题；
- 例如 Go 项目中，构建阶段链式执行 go mod download && go build -o app .，运行阶段直接 COPY 二进制，无需任何包管理器或源码。
慎用 && 连接符，注意失败退出逻辑
链式命令默认以 && 连接，任一命令返回非零状态即中断。这对可靠性是好事，但需注意：
- 不要把必须成功和可选操作混在同一 RUN 中（如日志清理失败不应导致构建失败）；
- 若某步可能失败但不影响后续，可用 || true 或 set +e 控制（但应明确注释原因）；
- 长链命令建议拆成逻辑块并换行缩进，提高可读性和调试性（Docker 会自动合并换行）。
