| 原则 | 变化越频繁的指令越靠后 |
|---|---|
| 典型模式 | 先 COPY 锁文件 → 安装依赖 → 再 COPY 源码 → 构建 |
| 观察 | 构建日志里的 CACHED 标记与耗时分布 |
Node 示例
Node 示例
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run buildRUN 指令合并要平衡：过度合并会让「某一步变化全部重跑」，按变化频率分界。
Dockerfile 层顺序与缓存命中
按变化频率排序：低频的依赖声明在前、易变的源码在后，使代码改动不触发依赖重装，构建缓存持续命中。
易错点
- 先 COPY . 再装依赖：改一行代码就重装全部依赖，构建时长成倍
- 锁文件与源码分开 COPY 后忘记更新：依赖层用旧锁，实际安装与仓库不一致
数据来源与参考
- Docker Docs《Best practices for writing Dockerfiles》