Docker构建未复用层的根本原因是构建上下文或指令微小变动触发逐层SHA256重算，导致后续所有层重建；常见诱因包括.dockerignore缺失、COPY与RUN顺序错误、ADD压缩包时间戳变化等。
为什么 docker build 重复构建时没复用已有 Layer？
根本原因不是缓存失效，而是构建上下文或指令微小变动触发了层重建。Docker 逐层计算 SHA256，只要某一层的输入（比如 COPY 的文件内容、RUN 命令字符串、甚至换行符）变了，它后面所有层都会重新生成。
常见诱因包括：
-
.dockerignore缺失，导致node_modules或__pycache__等临时目录被意外包含进上下文，每次npm install后哈希都不同 -
RUN pip install -r requirements.txt和COPY requirements.txt .顺序颠倒，导致每次改代码都重装依赖 - 使用
ADD加压缩包（会自动解压），而源文件时间戳变化，触发层变更
docker history 看到的
那是被后续镜像覆盖的旧层——Docker 不删除中间层，但新镜像的 manifest 不再引用它们，所以显示为 docker system prune。
关键点：
-
docker history --no-trunc才能看到完整指令和 layer ID - 同一层在不同镜像中可能有不同 ID（因为父层不同，整体哈希不同）
-
docker images --digests显示的是镜像 digest，不是 layer digest，别混淆
多阶段构建中 COPY --from=stage 能复用 layer 吗？
不能直接复用。虽然 COPY --from=builder /app /app 看似“复制”，但它生成的是一个全新 layer，内容相同但哈希不同，因为元数据（如创建时间、父层 ID）已变。
这意味着：
- 即使两个镜像都从同一个 builder stage 拷贝完全相同的二进制文件，它们的最终 layer ID 也不同
- 镜像推送/拉取时不会跳过该层，网络和存储开销照旧
- 想真正复用，得让目标镜像直接基于 builder 镜像 tag 构建（比如
FROM builder:latest），而非 COPY
如何确认某个 layer 是否被多个镜像共享？
Docker 本身不提供直接命令查 layer 引用关系，但可通过 docker system df -v 结合 docker image inspect 推断：
-
docker system df -v中的 “Shared Size” 列是估算值，实际共享逻辑更底层（基于 content-addressable store） - 运行
docker image inspect获取该镜像所有 layer ID 列表-f '{{.RootFS.Layers}}' - 对比多个镜像的 layer ID 数组，相同字符串即表示物理复用（注意：ID 长度一致且完全相等才算）
容易忽略的是：layer 共享只发生在同一台宿主机的同一 Docker daemon 实例内；不同机器、不同 daemon、或启用 containerd 直接拉取时，layer ID 可能因配置差异而无法对齐。
