docker镜像构建缓存复用机制基于分层存储与指令哈希协同实现，每层对应dockerfile一条指令，通过父层id、指令文本及关联文件内容三要素全等判定复用，任一变化即触发重建并使后续层失效。
镜像构建缓存复用机制是 Docker 架构中“分层存储 + 指令哈希”协同工作的结果，不是额外功能，而是底层设计的自然体现。它不依赖外部服务，完全由本地构建器根据确定性输入自动判断是否跳过某一层。
缓存从哪来：每一层都是一个只读快照
Docker 镜像本质是一组有序的只读层，每层对应 Dockerfile 中一条指令（FROM、RUN、COPY 等）。构建时，Docker 为每条指令生成唯一哈希值，依据三个要素：
- 上一层的 ID（父层必须完全一致）
- 当前指令的完整文本（包括空格、换行、注释）
- 该指令涉及的文件内容（如 COPY 的源文件实际字节）
三者全等，才复用已有层；任一变化，就触发重建，并使后续所有层失效。
缓存怎么断：常见“隐形破坏者”
很多看似无害的操作会意外清空缓存链：
- COPY . . 放太早：把 .git、logs、node_modules 一起复制进来，改个 README 就让整个依赖安装层重跑
- 基础镜像用 latest 或易更新 tag：ubuntu:22.04 可能悄悄变成新 digest，FROM 层已变，后面全崩
- RUN 中调用动态命令：比如 curl https://api/time 或 date +%s，每次输出不同，哈希必变
- ENV 或 ARG 值在构建中变更：哪怕只改一个版本号，后续所有依赖该变量的 RUN 都无法命中
缓存怎么稳：靠组织，不靠运气
真正提升命中率的关键，在于让“稳定部分”和“易变部分”物理隔离：
- 先 COPY 清单，再 RUN 安装：package.json → npm ci；requirements.txt → pip install；go.mod → go mod download
- 合并 RUN 并清理中间产物：apt-get update && apt-get install -y xxx && rm -rf /var/lib/apt/lists/*，避免残留文件引入随机性
- 用 .dockerignore 删干扰项：明确排除 .git、*.log、dist/、target/ 等不参与运行的文件
- 多阶段构建切域：编译放 builder 阶段，运行放 alpine 阶段，业务代码改动不影响编译缓存
缓存怎么活：BuildKit 让它跨构建、跨机器
默认缓存只在本机构建间有效。启用 BuildKit 后，可通过以下方式扩展能力：
- --mount=type=cache：在构建中挂载可复用的包缓存目录（如 ~/.pnpm、~/.cargo/registry），不进镜像但加速下载
- --cache-from / --cache-to：从远端镜像仓库拉取缓存层，构建完再推回去，CI 中实现“一次上传、全员受益”
- 固定 FROM digest：FROM node@sha256:abc123… 而非 node:20，彻底锁定起点，避免上游更新扰动
