Dockerfile指令顺序决定缓存命中率，稳定配置（如FROM、依赖安装）应置前，易变内容（如源码COPY）置后，合并RUN指令并合理使用.dockerignore可优化构建速度。
Dockerfile 中指令的书写顺序直接影响镜像构建时的缓存命中率，合理组织能显著加快构建速度、减少重复下载和编译。
缓存机制依赖指令顺序与内容一致性
Docker 构建时按顺序逐层执行指令，每条指令生成一个中间层。只要某一层的指令内容（包括上下文文件内容）未变，且其所有前置层都命中缓存，该层即可复用缓存。一旦某条指令缓存失效，后续所有指令都会重新执行，无法复用缓存。
- 修改 COPY . /app 前的任意指令（如 RUN apt update），会导致该 COPY 及之后所有层全部重建
- 把变动频繁的指令（如复制源码）放在靠后位置，可让前面稳定的配置（如安装系统包、设置环境变量）持续命中缓存
- 多阶段构建中，每个 FROM 都重置缓存链，但同一阶段内仍遵循顺序缓存规则
高频优化建议：分层原则与指令合并
核心是“稳定在前、易变更在后”，同时避免无谓的层分裂：
- 基础环境优先：先写 FROM、RUN 安装系统依赖（如 curl、build-essential）、设置 WORKDIR 和 ENV，这些很少改动
- 依赖单独提取：对语言包管理器（npm install、pip install、go mod download），先 COPY 依赖声明文件（package.json / requirements.txt / go.mod），再运行安装命令，确保依赖不变时跳过安装
- 源码最后复制：COPY 源代码应放在依赖安装之后，避免每次改代码都触发前面所有步骤重跑
- 合并 RUN 指令：多个 apt-get 命令应链式调用（apt-get update && apt-get install -y ... && rm -rf /var/lib/apt/lists/*），否则中间层残留的包列表会阻断后续缓存
常见陷阱：看似无关的改动实际破坏缓存
一些细微操作会意外导致缓存失效：
- .dockerignore 缺失：未忽略 node_modules、.git 等目录，导致 COPY . 时包含不必要文件，即使源码没变，时间戳或内容微小差异也会使缓存失效
- 指令语义等价但文本不同：RUN apt-get update && apt-get install foo 与 RUN apt-get update \&& apt-get install foo 在 Docker 看来是两条不同指令，缓存不共享
- 使用动态参数：RUN echo $BUILD_VERSION 或引用构建参数（ARG）但未在对应层显式声明，可能因参数值变化导致缓存跳过
- 时间敏感操作：RUN date > build-time.txt 这类指令永远无法缓存，应避免或移至构建外处理
验证与调试缓存是否生效
构建时观察日志中的 “Using cache” 提示是最直接方式；也可借助工具辅助分析：
- 添加 --progress=plain 参数查看详细缓存状态
- 用 docker image history
查看各层大小及是否为 “missing”（表示未缓存） - 临时注释部分指令，对比构建耗时变化，定位缓存断裂点
- 对关键层加 LABEL（如 LABEL layer=dependencies），便于后期追踪用途
