ci中go模块依赖问题主因是环境未对齐、校验被跳过或缓存失控；必须显式设go111module=on、确保工作目录为项目根、拆分go mod download与verify步骤、禁用go.sum自动更新、合理分离缓存与构建阶段。
CI里Go模块依赖出问题，八成不是代码写错了，而是环境没对齐、校验被跳过、或缓存没管好。
GO111MODULE=on 必须显式设置，不能靠Go版本默认
Go 1.16+ 虽默认启用模块模式，但很多CI环境（比如Jenkins旧Agent、golang:alpine镜像、或工作目录落在$GOPATH/src下）仍会退化回GOPATH模式——这时go build直接忽略go.mod，拉取最新版依赖，构建结果不可复现。
- 所有CI步骤开头加
env: GO111MODULE="on"，不赌默认行为 - CI工作目录必须是项目根（含
go.mod），别在$GOPATH/src里跑 - GitHub Actions中直接写
env:块；GitLab CI用variables:设全局环境变量
go mod download + go mod verify 必须拆成独立步骤
go build本身不校验go.sum，它会静默下载缺失模块、跳过哈希比对。CI里漏掉这两步，等于把门敞开给被污染的代理缓存或中间人篡改。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
go mod download确保所有依赖可获取且版本锁定（避免测试时并发拉包超时） -
go mod verify必须紧跟其后，失败立即中断流水线（返回非零码） - 若用私有代理（如Athens），还需额外配置
GOPROXY并验证TLS证书有效性
go.sum自动更新必须禁用，GOSUMDB要按场景选
默认GOSUMDB=sum.golang.org依赖外部服务，在CI中容易因防火墙、DNS不稳定或网络策略超时失败；但直接设GOSUMDB=off又等于放弃校验能力。
- 推荐方案：CI中设
GOSUMDB=off，但前提是go.sum已提交且严格受控——每次依赖变更后，本地运行go mod tidy并提交更新后的go.sum - 若需在线校验，改用可信内网
GOSUMDB服务，或设GOSUMDB=off+ 手动比对go.sum哈希 - 绝对禁止CI中让
go mod download或go build自动修改go.sum
缓存和多阶段Docker构建要分离模块下载
CI缓存$HOME/go/pkg/mod能提速，但若把go mod download和go build塞进同一个Docker构建阶段，缓存失效时会重复下载+编译，浪费资源且易触发代理限流。
- GitHub Actions用
actions/cache@v4缓存$HOME/go/pkg/mod和$HOME/go/build-cache - Docker多阶段构建中，第一阶段只做
go mod download，第二阶段COPY --from=0 $GOMODCACHE /go/pkg/mod复用 - 多模块项目（如monorepo）需注意：
go list -m all只显示当前目录go.mod的依赖，跨模块调用要用replace指令显式声明
最常被忽略的是：go.sum不是“锁文件”而是校验快照，它的内容必须与go.mod和实际下载包完全对应——CI里任何绕过校验、容忍哈希不匹配的操作，都在为生产事故埋点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
