根本原因是go111module、goproxy、goinsecure及go.mod中replace/exclude的组合行为在多层构建/ci环境中被意外覆盖或延迟生效，尤其在项目嵌套、存在vendor目录或使用自定义build flags时；go mod download严格依据当前go.mod和环境变量解析路径，不读取vendor/modules.txt，也不受-mod=vendor影响，导致本地与ci环境路径不一致。
Go 模块依赖下载路径漂移，根本原因不是网络或代理问题，而是 GO111MODULE、GOPROXY、GOINSECURE 和本地 go.mod 中 replace / exclude 的组合行为在多层构建/CI环境里被意外覆盖或延迟生效——尤其当项目嵌套、存在 vendor 目录、或使用了自定义 build flags 时。
为什么 go mod download 会拉错路径（比如从 proxy 拉成 direct，或绕过 replace）
常见现象：本地 go build 正常，但 CI 中执行 go mod download 后 go list -m all 显示的 module path 和本地不一致；或者 go mod verify 失败，提示 checksum mismatch。
-
GO111MODULE=auto在非模块根目录下可能退化为 GOPATH mode，忽略go.mod中的replace -
GOPROXY设为direct或包含多个逗号分隔地址时，Go 会按顺序尝试，一旦某个源返回 404 就 fallback 到下一个——而某些私有 registry 对未授权请求返回 200+ 空响应，导致 Go 误判为“存在”，后续跳过replace规则 -
go mod download默认不读取vendor/modules.txt，也不受-mod=vendor影响；它只依据当前模块的go.mod和环境变量做解析
如何锁定下载路径：强制走 replace 且绕过 proxy 校验
核心思路是让 Go 在 resolve 阶段就确定路径，而不是等 download 阶段再决策。适用于私有模块、fork 仓库、或需要固定 commit 的场景。
- 在
go.mod中用绝对路径写replace，例如：replace github.com/foo/bar => /path/to/local/bar（本地路径）或replace github.com/foo/bar => github.com/myfork/bar v1.2.3-0.20230101000000-abcdef123456（伪版本） - 设置
GOPROXY=off或GOPROXY=direct，并同时设GOINSECURE="*.internal,192.168.0.0/16"（若用私有 HTTPS registry 且证书不可信） - 避免在命令行传
-mod=readonly或-mod=vendor给go mod download——它不认这些 flag；真正起作用的是go mod download -x查看实际 fetch URL，确认是否命中预期源
go build 和 go mod download 行为不一致的典型诱因
这不是 bug，而是 Go 模块加载阶段分离导致的——build 可能复用已缓存的 module，而 download 强制重新解析依赖图。
- 执行过
go mod vendor后，go build -mod=vendor完全不联网，但go mod download仍会按go.mod去远程拉取，不受 vendor 影响 - CI 中使用 Docker 多阶段构建时，如果
builder阶段没运行go mod download，而runner阶段又清空了$GOCACHE和$GOPATH/pkg/mod，就会触发重复 resolve，此时若环境变量缺失，路径立即漂移 -
CGO_ENABLED=0或GOOS=js等编译选项本身不影响 module resolution，但若它们导致go list -deps输出不同（如忽略 cgo-only 依赖），就会间接改变go mod download的目标集
最易被忽略的一点：Go 不校验 go.mod 文件本身的来源——如果你用脚本动态生成或 patch go.mod，必须确保它在 go mod download 执行前已落盘且未被 git clean 清掉；否则 Go 会静默回退到上一个有效的 go.mod，路径自然就偏了。
