docker镜像构建应将不变指令前置、可变指令后置以最大化缓存命中率：固定基础镜像、合并安装清理命令、前置依赖文件复制安装、源码及配置分批靠后copy、多阶段构建隔离编译与运行环境。
核心就一条：把几乎不变的指令放前面，把总在变的指令放后面。Docker 是逐层构建的，前一层一变，后面所有层全得重来——所以顺序比写法本身还重要。
基础环境和系统依赖优先
FROM、系统包安装、环境变量设置这些内容很少改动，必须放在最开头：
- 用固定标签，比如 FROM python:3.11.9-slim-bookworm，别用
latest或浮动版本，否则基础镜像悄悄更新，缓存看似命中实则底层已变 - 合并 apt/apk 安装与清理：RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*，避免中间层残留索引文件导致后续缓存断链
- 别在 RUN 里调用
date、curl https://time.api这类每次结果不同的命令，它们会让哈希值永远不一致
依赖声明和安装单独前置
应用依赖（requirements.txt、package.json、go.mod）比源码稳定得多，要先复制、再安装：
- 先 COPY requirements.txt .，再 RUN pip install -r requirements.txt；这样改一行代码不会触发重装依赖
- Node.js 项目同理：COPY package*.json . && npm install，之后再 COPY . .
- 配合 .dockerignore 排除
node_modules、__pycache__、.git等，防止这些目录被意外 COPY 进来，破坏缓存一致性
源码最后复制，按逻辑分批
业务代码天天改，必须放到靠后位置，而且别一股脑全拷贝：
- COPY src/ . 比 COPY . . 更安全，改个 README.md 不会连带让前面的 pip install 层失效
- 配置文件、静态资源可单独分批 COPY：COPY config/ . → COPY static/ . → COPY src/ .，隔离变更影响范围
- 每条 RUN 尽量串起关联操作，比如 RUN pip install && python manage.py collectstatic --noinput && rm -rf /app/staticfiles/.git，减少无谓层数
多阶段构建精准控制缓存边界
每个 FROM 都会重置缓存链，但同一阶段内仍遵循顺序规则，这是隔离变更最有效的手段：
- 构建阶段只 COPY
go.mod或Cargo.toml，RUNgo mod download或cargo build --release；只要依赖没变，这部分就一直复用 - 运行阶段用 COPY --from=builder /src/app . 提取二进制，完全跳过编译，也不引入 gcc、rustc 等构建工具
- 实测某 Go 服务拆分后，CI 构建从 3 分 18 秒降到 27 秒，缓存命中率稳定在 94% 以上
不复杂但容易忽略。
