核心是让COPY指令复用缓存层：先拷贝稳定依赖文件（如package.json）、RUN安装，再拷贝易变源码；配合.dockerignore排除干扰、多阶段构建隔离、BuildKit提升效率，确保小改动不触发整链重跑。
核心思路是让缓存尽可能“稳住”，避免一丁点改动就全盘重来。关键不在删缓存，而在设计让缓存能真正复用。
调整 COPY 指令顺序，把稳定内容放前面
Docker 缓存按层逐条比对，只要某一层变了，后面全得重跑。源码天天改，但依赖描述文件（如 package.json、requirements.txt）改得少。所以得先复制它们、装依赖，再复制源码。
- ✅ 正确写法（Node.js 示例）：
COPY package.json .<br>RUN npm install<br>COPY . .
- ❌ 错误写法：
COPY . .<br>RUN npm install
—— 一行代码改了，npm install 就必须重来 - 多语言同理：Python 项目先 COPY requirements.txt 再 pip install；Java 项目先 COPY pom.xml 再 mvn dependency:resolve
用 .dockerignore 切断上下文污染
Docker 构建时默认把当前目录整个打包传进构建器，哪怕你只改了一个 .js 文件，只要 node_modules 或 .git 在目录里，它们的哈希值也会参与缓存计算，导致缓存总不命中。
- 在项目根目录建
.dockerignore，至少包含：node_modules/<br>.git/<br>.DS_Store<br>*.log<br>dist/<br>build/
- 检查是否生效：运行
docker build --progress=plain .，看日志里 “Sending build context” 的大小——理想应控制在几 MB 内
锁定基础镜像和依赖版本
缓存失效常因底层“悄悄变了”：比如 FROM node:latest 实际拉到的是新版 node，哈希值不同，第一层就崩了；pip install flask 不指定版本，下次可能装新 patch 版，第二层也崩。
- 基础镜像务必带明确标签：
FROM node:18.17.0-slim或FROM python:3.11.9-slim，不用 latest、slim 等浮动标签 - 依赖文件中固定版本：
package.json 里"express": "4.18.2"，不用^4.18.0；
requirements.txt 用requests==2.31.0，加--no-deps或--freeze确保可重现
启用 BuildKit 并配置远程缓存（CI 场景必备）
本地缓存只对单机有效；CI 流水线每次都是新机器，必须靠远程缓存接力。BuildKit 是现代构建引擎，支持高效缓存共享。
- 启用 BuildKit：
环境变量DOCKER_BUILDKIT=1，或 CLI 加--builder=buildkit - 推送缓存到镜像仓库（如 Harbor、ECR）：
docker build --cache-to type=registry,ref=my-registry/cache:app --cache-from type=registry,ref=my-registry/cache:app -t myapp:latest . - 配合 CI 工具（GitHub Actions / GitLab CI），把缓存 ref 绑定分支名或 commit hash，避免 dev 和 main 分支互相干扰
