定位缓存失效起点需查找构建日志中首个未出现“Using cache”的指令行，该行为断点，其后所有层均重建；再结合Dockerfile检查COPY/ADD源文件、FROM镜像digest、RUN等指令文本及构建上下文是否变更。
直接看构建日志里哪一行开始没了 Using cache，就是缓存被破坏的起点。Docker 是从上往下逐层比对的，一旦某层没命中，它后面所有层都会重建，所以定位第一个“断点”最关键。
观察构建输出，锁定失效起始层
运行 docker build 时，默认日志会显示每条指令的状态：
- 看到 Using cache 或 CACHED，说明该层复用了缓存
- 看到 Running in ...、Downloading...、Step X/XX : RUN ... 并开始执行命令，说明缓存在此中断
- 从这一行开始，后续所有步骤都必然重新执行，无需再往下找“第二个断点”
对照 Dockerfile，检查该层及前一层的输入是否变化
找到失效指令后，重点排查它的直接输入是否发生变更：
-
如果是 COPY 或 ADD：检查复制的源文件（如
package.json、requirements.txt、.env）内容是否改动——哪怕一个空格、时间戳或注释变化都会导致哈希不同 -
如果是 FROM：用
docker inspect 镜像名 --format='{{.RepoDigests}}'查当前基础镜像 digest；再对比上次构建用的 digest 是否一致。标签相同（如node:18-alpine）不代表 digest 不变 -
如果是 RUN、ENV、ARG：确认指令文本完全一致（包括空格、换行、分号位置）；若含
--build-arg，检查传入值是否变化（例如--build-arg BUILD_TIME=$(date)必然失效）
验证上下文是否“悄悄”变了
即使 Dockerfile 没改，构建上下文也可能触发失效：
- 运行
ls -la和git status，确认工作目录没有新增/修改/删除的文件（尤其是隐藏文件） - 检查
.dockerignore是否生效：用docker build --no-cache -q .输出的上下文大小，和上次构建对比是否明显增大（比如多出node_modules或.git） - 在 CI 环境中，注意 Git 仓库 shallow clone、checkout 方式（如
fetch-depth: 1）、或自动注入的环境变量可能影响上下文哈希
用 --progress=plain 查看底层缓存键细节
启用详细模式能暴露更多线索：
- 加参数
docker build --progress=plain . - 关注输出中类似
CACHE KEY ...或cache key not found的行，它会标明具体是哪个文件或指令哈希不匹配 - 配合 BuildKit（
DOCKER_BUILDKIT=1）时，还能看到 content-based hash 计算结果，精准定位哪个文件内容变了
