docker构建缓存基于指令层哈希比对，输入一致则复用中间镜像层；基础镜像digest变更、文件内容改动、指令文本变化或build-arg参数不同均导致该层及后续层失效。
理解Docker构建缓存的基本机制
Docker在执行docker build时，会逐层解析Dockerfile中的指令。每条指令（如COPY、RUN、ADD）都会生成一个中间镜像层。如果某一层的输入内容（包括指令本身、上下文文件、基础镜像等）与之前构建完全一致，Docker就复用已有的缓存层，跳过执行；一旦某层不匹配，后续所有层都会失效并重新构建。
哪些操作会触发缓存失效
缓存失效不是随机发生的，而是由明确的比对规则决定。常见触发点包括：
-
基础镜像更新：比如
FROM ubuntu:22.04对应镜像被重新打标签或更新，即使版本号没变，其digest变了，FROM层就失效 -
文件内容变更：使用
COPY . /app时，只要工作目录中任一文件的mtime或内容变化，该层及之后全部重建 -
指令文本变动：哪怕只是RUN命令里多了一个空格、换了一种包管理器写法（如
apt-get update && apt-get install -y curlvsapt-get update && apt-get install -y wget），RUN层立即失效 -
构建参数变化：使用
--build-arg传入不同值，且该参数用于RUN或ENV指令中，对应层也会失效
如何主动控制缓存行为提升构建效率
合理组织Dockerfile顺序和指令粒度，能显著减少不必要的重建：
-
把变动少的指令放前面：例如先
COPY package.json /tmp/再RUN npm install，比直接COPY . /app更利于缓存复用 -
合并相关RUN命令：用
&&链式执行，避免产生多余中间层（每条RUN都是一层，单独写会导致前一层缓存无法被后一层利用） - 用.dockerignore排除无关文件：防止日志、node_modules、.git等干扰COPY上下文哈希计算
-
指定精确的基础镜像摘要：用
FROM ubuntu@sha256:abc123...替代FROM ubuntu:22.04，避免因镜像更新意外失效
验证和调试缓存是否生效
构建时观察输出是最快判断方式：
- 看到Using cache表示该层命中缓存
- 出现CACHED或跳过执行日志，说明复用成功
- 若某层开始显示Running in ...或下载/编译动作，则从该层起全部重建
- 加
--progress=plain参数可查看更详细的层ID和缓存状态
