Docker 镜像构建信息查看如何分析缓存命中情况

直接看构建日志即可判断缓存是否命中：Using cache表示命中，Running in或新哈希值出现表明未命中，--progress=plain可查看详细缓存键，结合上下文哈希、.dockerignore配置及基础镜像digest比对，能精准定位缓存断裂原因。

直接看构建日志就能判断缓存是否命中，不需要额外工具。Docker 默认输出里藏着关键线索，重点抓几个词、几处变化，就能快速定位哪一层断了、为什么断。

盯紧日志里的关键词

Docker 构建时每层都会打印状态，这些提示就是缓存的“晴雨表”：

1. Using cache：这一层完全复用，父层一致、指令没改、上下文也没变
2. Running in 或 Step X/Y 后紧跟命令执行（比如 RUN npm install 开始下载）：说明这层没命中，正在重新跑
3. sha256:xxx 或旧版中的 CACHED：确认该层确实用了缓存
4. 某行原本是 ---> Using cache，下一次却变成 ---> abc123def（新哈希）：这就是缓存断裂点，从这层开始全重来

开 plain 模式看清缓存键

加 --progress=plain 参数运行构建，日志会详细列出每一层的缓存键构成：

1. 它会显示这一层依赖哪些文件路径、这些文件的哈希值、指令文本的哈希、基础镜像的 digest
2. 如果某层突然从 MISSED 变成 CACHED（或反过来），对比前后两行的哈希字段，就能看出是哪个文件内容变了、mtime 被更新了，还是 FROM 镜像 digest 不同了
3. 建议配合 --no-cache=false 显式启用缓存，避免因配置问题误判为全局禁用

检查上下文有没有偷偷“污染”

即使没写 COPY，Docker 也会为整个构建目录算哈希。只要上下文里多了个临时文件，所有依赖上下文的层都可能失效：

1. 用 tar -cf - . | sha256sum 对比两次构建前的上下文哈希，不一样就说明上下文本身在变
2. 检查 .dockerignore 是否漏掉了 node_modules、.git/index、npm-debug.log、.DS_Store 这类高频变动项
3. 运行 find . -type f -newermt "1 hour ago" | head -20 快速找出刚被修改的干扰文件

确认基础镜像有没有漂移

FROM 行看着没动，但远程镜像可能已更新。常见表现是第一层就重建：

1. 先 docker pull ubuntu:22.04，再构建，看是否还重建；如果不重建了，说明原缓存基于旧 digest
2. 查当前 digest：docker inspect $(docker images ubuntu:22.04 -q) --format='{{.RepoDigests}}'
3. 把 Dockerfile 中的 FROM ubuntu:22.04 改成 FROM ubuntu@sha256:abc...，彻底锁定基础层

不复杂但容易忽略