docker多阶段构建不存在“缓存穿透”，本质是缓存未命中：需确保go.mod/go.sum精准前置复制、排除.git等干扰文件、用--cache-from复用builder镜像、通过构建日志验证cached状态。

docker 多阶段构建本身不会发生“缓存穿透”——这个词在 docker 构建语境中属于误用。缓存穿透是缓存系统（如 redis）领域的术语，指查询不存在的数据导致请求直击后端数据库；而 docker 构建缓存是本地只读的层式快照机制，不存在“穿透”逻辑。

你真正想问的，很可能是：
✅ 如何避免多阶段构建中因依赖或上下文变化导致的缓存失效（即“缓存不命中”或“缓存被意外跳过”）？
也就是：为什么明明没改 go.mod，go mod download 还是重新执行？为什么 --from=builder 阶段的产物总不能复用？这常被开发者口语化称为“缓存没起来”“缓存穿透了构建流程”，但本质是缓存未命中或缓存被破坏。

下面从实操角度给出针对性解法：

一、确保构建阶段的输入稳定，让缓存可复用

Docker 缓存是否命中，取决于指令内容 + 构建上下文文件内容是否与历史完全一致。多阶段中尤其要注意 builder 阶段的稳定性。

• COPY go.mod go.sum . 必须紧邻 RUN go mod download，且中间不能插入其他可能变动的指令（如 COPY . . 或 RUN date）
• 确保 go.sum 文件真实存在且未被 .dockerignore 排除（常见坑：.git 被忽略，但 go.sum 在 .git 下生成，CI 中缺失）
• 不要使用 COPY . . 提前覆盖 go.mod，否则后续 COPY go.mod . 实际复制的是旧内容，缓存校验失败

二、显式控制 builder 阶段的缓存来源

默认情况下，Docker 只复用本地已有的中间镜像。CI/CD 中需主动注入缓存：

• 构建时指定上游缓存镜像：

  docker build --cache-from=myapp:builder-latest --target builder -t myapp:builder-latest .

• 推送 builder 镜像到仓库（如 myapp:builder-latest），供下一次构建拉取复用
• 配合 --target builder 精确构建特定阶段，避免运行无关指令干扰缓存链

三、隔离易变内容，防止污染 builder 缓存层

即使使用多阶段，若 builder 阶段包含时间戳、随机数、Git commit hash 等动态内容，也会导致缓存失效：

• ❌ 错误写法（引入非确定性）：

  RUN echo "build at $(date)" >> version.txt  # 每次都不同 → 缓存失效
  COPY . .  # 复制了日志、.git、node_modules 等，哈希总变

• ✅ 正确做法：
  • 用 .dockerignore 排除 node_modules, .git, logs/, *.log, *.md 等
  • 将版本信息等动态内容移到 final 阶段注入（不影响 builder 缓存）
  • 如需 commit ID，用 ARG BUILD_COMMIT 传入，而非 RUN git rev-parse HEAD

四、验证缓存是否真实生效

别凭感觉判断——看构建日志最可靠：

• 命中缓存时显示 CACHED 或 Using cache
• 若某层显示 sha256:xxx: Pulling fs layer 或 Running in container，说明未命中
• 可加 --progress=plain 查看每步耗时与缓存状态：

  docker build --progress=plain --target builder .

不复杂但容易忽略