本质是某层输入发生不可见变化，导致该层及后续所有层重建；排查重点为“本应稳定却变动”的层，需结合构建日志（Using cache提示）、.dockerignore配置、FROM标签稳定性、ARG隐性变更及docker image history分析层ID与体积异常。
顺序不当导致缓存失效，本质是 docker 构建时某一层的输入发生了不可见变化，从而让该层及之后所有层全部重建。排查重点不在“哪一层变了”，而在于“哪一层不该变却变了”——尤其是那些本应稳定、却被前置变动牵连的层。
看构建日志里哪一层开始重新执行
运行 docker build --no-cache=false（默认行为），观察输出。Docker 会逐行打印每条指令，并标注 Using cache 或 Building in progress。一旦出现某个 RUN 或 COPY 没有命中缓存，且它前面的层都命中了，那问题就出在这一层或它的直接上游。
注意：如果从第一个 RUN 就没缓存，大概率是基础镜像（FROM）变了，或者构建上下文里有个隐藏文件被修改了（比如 .git/index、.DS_Store、编辑器临时文件）。
检查 COPY/ADD 的文件范围是否过宽
COPY 指令只要涉及的文件内容有变化，整层就失效。常见陷阱：
- COPY . . 把整个目录拖进去，包括日志、node_modules、target/ 等构建产物 —— 这些文件每次 build 都不同，导致缓存必然断裂
- COPY src/ . 看似合理，但如果 src/ 下混入了自动生成的配置或时间戳文件，也会污染缓存
- 没用 .dockerignore 排除无关文件，让 Docker 在计算缓存哈希时把不该算的文件也纳入了
验证 FROM 和 ARG 是否隐性变动
这两处最容易被忽略，但影响最广：
- FROM ubuntu:22.04 看似固定，实则这个 tag 是滚动更新的。某天上游镜像层变了，你的整个构建链就全失效 —— 建议改用 digest，如 FROM ubuntu@sha256:abc123...
- ARG BUILD_VERSION 如果在 FROM 中使用（如 FROM my-base:$BUILD_VERSION），而构建时没传值或传值不一致，Docker 会用空字符串或默认值，造成层哈希不匹配
- ARG 出现在 ENV 后面，又参与了 RUN 命令（如 RUN echo $VERSION > version.txt），那只要 ARG 值一变，这层就失效
用 docker image history 定位可疑层
构建完成后，运行：
docker image history <image-id>
查看每层的大小和创建命令。重点关注：
- 某层体积异常大（比如几百 MB），很可能是 COPY 了不该带的东西
- 同一指令在不同机器上生成的层 ID 不一致，说明输入内容实际不同（比如时间戳、随机数、构建路径）
- 某层 CREATED 时间非常新，而其他层都是几天前的，说明它最近被强制重建过
