go mod download必须放在COPY . .之前，因为Docker层缓存依赖输入文件哈希，若先复制全部源码，代码变更会导致整个目录哈希变化，使依赖下载层无法复用；而单独复制go.mod/go.sum后再执行go mod download，可确保仅当依赖声明变更时才重新下载，大幅提升构建速度。
直接结论：依赖缓存是否生效，取决于 go.mod 和 go.sum 是否在 go mod download 之前被复制，且该步骤必须独立成层、不被后续代码变更污染。
为什么 go mod download 必须放在 COPY . . 之前
Docker 层缓存只对指令内容和输入文件哈希敏感。如果先 COPY . . 再 go mod download，每次改一行业务代码，整个目录哈希就变，go mod download 这层必然失效，导致每次构建都重下所有模块。
-
go.mod和go.sum文件变更频率极低（通常只在增删依赖时变动），把它们单独COPY并立即执行go mod download，能稳定命中缓存 - 后续
COPY . .复制源码，哪怕改了main.go，也不会影响前面已缓存的依赖层 - 若项目使用 vendor 目录，应改用
COPY vendor ./vendor+go build -mod=vendor，但注意 vendor 路径必须与导入路径严格一致（如vendor/github.com/sirupsen/logrus/→/go/src/github.com/sirupsen/logrus/）
多阶段构建中依赖缓存的实际写法
builder 阶段的前几行决定缓存效率。错误写法是把 go.mod、go.sum 和源码一起 COPY；正确写法必须拆开。
- 第一阶段开头固定三步：
COPY go.mod go.sum ./→RUN go mod download→COPY . . - 务必在
go mod download后加-x参数临时调试一次，确认下载路径是否为/go/pkg/mod/（Docker 默认 GOPATH 下的缓存位置） - 若 CI 环境网络受限，可在
RUN前加ENV GOPROXY=https://goproxy.cn,direct，避免因代理失败 fallback 到直连超时 - 不要在
RUN go mod download后加&& go mod verify——go mod download已隐式校验go.sum，重复执行纯属冗余
CGO_ENABLED=0 和静态编译对依赖缓存的影响
静态编译本身不改变模块下载行为，但它决定了最终二进制能否脱离 builder 阶段运行。一旦设错，runtime 阶段会因缺失 libc 或证书而启动失败，让人误以为“缓存没生效”。
立即学习“go语言免费学习笔记（深入）”；
-
CGO_ENABLED=0必须在go build时显式设置，否则即使go mod download缓存命中，生成的二进制仍动态链接，无法在scratch或distroless中运行 - 若项目实际依赖 cgo（如 SQLite、某些图像库），不能简单设
CGO_ENABLED=0，需改用alpine作为 runtime 基础镜像，并RUN apk add --no-cache sqlite-dev - 静态编译后，
go build不再读取$GOMODCACHE，但go mod download层仍起作用 —— 因为它保障了 builder 阶段的编译环境完整性
容易被忽略的缓存破坏点
很多团队花时间调 proxy 却收效甚微，问题其实出在 Dockerfile 的细节上。
-
.dockerignore必须包含node_modules/、vendor/（如果不用 vendor）、**/*.md等非必要文件，否则COPY . .会把无关内容带入构建上下文，增大 layer size 并可能触发意外缓存失效 - 本地开发时若挂载
GOCACHE目录到容器（如-v $PWD/.go/cache:/.cache/gocache），要确保该目录权限为 755 且属主 UID 匹配容器内用户，否则go build可能静默跳过缓存 - CI 环境中若使用自建 registry 或私有 proxy，需在
RUN指令里显式export GOPROXY=...，不能只靠ENV—— 某些旧版 Docker 在 multi-stage 中 ENV 不跨阶段继承
真正卡住构建速度的，往往不是网络或代理，而是某次 go.mod 格式化、空格调整或注释增删导致哈希变化，让整个依赖层失效。盯住那两行 COPY 和紧随其后的 RUN，比优化 proxy 更立竿见影。
