直接看构建日志即可判断缓存是否命中：using cache表示命中，running in或新哈希值出现表明未命中，--progress=plain可查看详细缓存键，结合上下文哈希、.dockerignore配置及基础镜像digest比对，能精准定位缓存断裂原因。
直接看构建日志就能判断缓存是否命中，不需要额外工具。Docker 默认输出里藏着关键线索，重点抓几个词、几处变化，就能快速定位哪一层断了、为什么断。
盯紧日志里的关键词
Docker 构建时每层都会打印状态，这些提示就是缓存的“晴雨表”：
- Using cache：这一层完全复用，父层一致、指令没改、上下文也没变
-
Running in 或 Step X/Y 后紧跟命令执行（比如
RUN npm install开始下载）：说明这层没命中，正在重新跑 - sha256:xxx 或旧版中的 CACHED：确认该层确实用了缓存
- 某行原本是
---> Using cache，下一次却变成---> abc123def（新哈希）：这就是缓存断裂点，从这层开始全重来
开 plain 模式看清缓存键
加 --progress=plain 参数运行构建，日志会详细列出每一层的缓存键构成：
- 它会显示这一层依赖哪些文件路径、这些文件的哈希值、指令文本的哈希、基础镜像的 digest
- 如果某层突然从 MISSED 变成 CACHED（或反过来），对比前后两行的哈希字段，就能看出是哪个文件内容变了、mtime 被更新了，还是
FROM镜像 digest 不同了 - 建议配合
--no-cache=false显式启用缓存，避免因配置问题误判为全局禁用
检查上下文有没有偷偷“污染”
即使没写 COPY，Docker 也会为整个构建目录算哈希。只要上下文里多了个临时文件，所有依赖上下文的层都可能失效：
- 用
tar -cf - . | sha256sum对比两次构建前的上下文哈希，不一样就说明上下文本身在变 - 检查
.dockerignore是否漏掉了node_modules、.git/index、npm-debug.log、.DS_Store这类高频变动项 - 运行
find . -type f -newermt "1 hour ago" | head -20快速找出刚被修改的干扰文件
确认基础镜像有没有漂移
FROM 行看着没动，但远程镜像可能已更新。常见表现是第一层就重建：
- 先
docker pull ubuntu:22.04，再构建，看是否还重建；如果不重建了，说明原缓存基于旧 digest - 查当前 digest：
docker inspect $(docker images ubuntu:22.04 -q) --format='{{.RepoDigests}}' - 把 Dockerfile 中的
FROM ubuntu:22.04改成FROM ubuntu@sha256:abc...，彻底锁定基础层
不复杂但容易忽略
