go mod download 总是不命中缓存，根本原因是 copy . . 过早引入变动上下文，导致 go.mod/go.sum 层输入哈希失效；必须单独前置 copy go.mod go.sum、紧邻 run go mod download、配合严格 .dockerignore 和 buildkit 内容寻址才能稳定复用缓存。
Go 应用的 Docker 构建，缓存失效是比镜像体积更大的隐形瓶颈——go mod download 每次都重跑，go build 从头编译，CI 构建时间翻倍，根本不是“多阶段”本身的问题，而是依赖层没对齐缓存边界。
为什么 go mod download 总是不命中缓存？
Docker 缓存只认指令内容和上一层哈希。如果 COPY . . 放在 go mod download 前面，哪怕只改了一个空格，整个构建上下文变了，COPY go.mod go.sum ./ 这一行的输入层就不同，后续所有缓存全失效。
- 必须把
go.mod和go.sum单独、尽早 COPY，且仅这两个文件 - 禁止在它们之后、
go mod download之前插入任何其他COPY或RUN - 确保
.dockerignore里包含/vendor、node_modules、README.md等干扰项，否则COPY . .实际传入的上下文哈希会变
如何让 builder 阶段的 GOPATH 缓存复用？
默认情况下，每个构建都是干净 GOPATH，go mod download 下载的包不会跨构建保留。但 Docker 层缓存本身就能复用已下载的模块——前提是下载动作被固化为独立层，且该层输入未变。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 写成
COPY go.mod go.sum ./→RUN go mod download，这两行必须紧邻，中间不能有空行或注释（Docker 会把空行也当作层变更） - 不要合并成
RUN go mod download && go build，否则只要 build 命令改了，download 层也失效 - 如果用了
GO111MODULE=on（Go 1.16+ 默认开启），无需显式设置，但确认go env GOMODCACHE路径在构建阶段内一致（默认/go/pkg/mod）
多阶段间如何安全共享编译产物而不带进调试工具？
COPY --from=builder 只复制指定路径下的文件，但容易漏掉运行时依赖——比如 TLS 证书、cgo 动态库、甚至 /etc/passwd（某些 alpine 镜像启动失败就是因为这个）。
- 静态编译优先：设
CGO_ENABLED=0，避免 cgo 引入 glibc 依赖 - 若必须用 cgo（如 sqlite、openssl），则第二阶段不能用
scratch，得选gcr.io/distroless/base或alpine:latest，并补RUN apk add --no-cache ca-certificates - 证书问题最常见：alpine 的
ca-certificates安装后证书路径是/etc/ssl/certs/ca-certificates.crt，而 builder 阶段是/etc/ssl/certs，直接COPY --from=builder /etc/ssl/certs/ .会出错，应精确复制文件而非目录
BuildKit 开启后，缓存行为有什么实际变化？
传统构建器按顺序逐层比对，BuildKit 则用内容寻址存储（CAS），对 go mod download 输出的模块树做哈希校验，即使构建顺序微调，只要最终模块集合一致，就复用缓存。
- 必须启用：
export DOCKER_BUILDKIT=1，CI 中建议写进 CI 脚本开头 - BuildKit 下
RUN --mount=type=cache,target=/go/pkg/mod可显式挂载模块缓存，但对纯 Go 项目收益有限——因为go mod download层本身已足够稳定 - 注意：BuildKit 默认禁用
docker build --no-cache的强制刷新逻辑，某些旧 CI 流程需显式加--progress=plain查看真实日志
真正卡住缓存的，往往不是语法或阶段命名，而是 go.mod 文件里一个没 pin 死的 minor 版本号、或者 .dockerignore 漏掉了一个隐藏文件——这些细节不爆错，但会让每一层缓存都变成一次性消耗品。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
