核心在于让 Docker 复用已构建的层，避免重复执行耗时操作。关键不是“能不能复用”，而是“如何让缓存稳定命中”。
把不变的部分尽量往前放
镜像层缓存按顺序逐层比对，一旦某层内容变化，它之后所有层都会重建。所以要把最稳定、最少改动的内容放在 Dockerfile 开头。
- 先 COPY 依赖清单（如
requirements.txt或package.json），再 RUN 安装命令；只要清单没改，安装步骤就直接用缓存 - 基础镜像（
FROM）、系统工具安装（RUN apt-get update && apt-get install）这些低频变更项也应靠前 - 源码文件（
COPY .）务必放在最后——它几乎每次提交都变，放前面会让后续所有层失效
减少无效层和干扰因素
每一层都可能成为缓存断点，不合理的写法会悄悄破坏复用机会。
- 合并连续的
RUN命令，比如把apt-get update和install写在同一行，并清理缓存：RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* - 用
.dockerignore排除node_modules、__pycache__、日志、.git 等无关文件，防止它们被传入构建上下文、意外触发 COPY 层重建 - 避免在
COPY中使用宽泛路径（如COPY . /app），若只需部分文件，明确指定，降低哈希校验误命中风险
善用高级构建能力提升复用粒度
原生缓存只看指令文本和文件内容，而现代构建引擎支持更精细的复用控制。
- 启用 BuildKit（Docker Desktop 默认开启，Linux 可设
DOCKER_BUILDKIT=1），支持RUN --mount=type=cache，让 pip/npm 在多次构建间共享下载缓存目录 - 多阶段构建中，用
COPY --from=builder只复制编译产物，不带构建工具链，既减小体积又避免运行时层被构建层污染 - 配置远程缓存（如
--cache-to type=registry,ref=myreg/cache:myapp），让 CI 流水线之间也能共享中间层，新节点首次构建不再从零开始
验证和调试缓存是否真正生效
别凭感觉判断优化效果，要看得见缓存行为。
- 构建时加
--progress=plain，观察每步是否显示Using cache；若某步变成...后跟耗时数字，说明缓存已失效 - 对比优化前后
docker image history your-image输出：层数是否减少、各层大小是否更合理、是否有大量空层或重复操作 - 临时加
--no-cache构建一次，确认耗时是否明显回升——这是反向验证缓存价值最直接的方式
