CI中应使用go mod download而非go mod tidy，因后者会修改go.mod和go.sum导致构建不可重现；前者仅下载依赖不改动文件，并需配合GOPROXY和GOSUMDB统一配置以确保可重现性。
Go CI 中 go mod download 和 go mod tidy 该用哪个？
CI 流水线里最常犯的错误，是把 go mod tidy 当成“下载依赖”的命令来用。它实际会修改 go.mod 和 go.sum，可能意外引入新版本或删掉未显式引用的模块，导致构建不可重现。
正确做法是：CI 中只运行 go mod download（配合 GOPROXY），确保所有依赖已缓存；go mod tidy 应仅在开发阶段手动执行，并提交变更后的 go.mod 和 go.sum。
-
go mod download不修改任何文件，只拉取模块到本地GOPATH/pkg/mod - 若 CI 报错
missing go.sum entry，说明本地go.sum不完整，应检查是否跳过了git add go.sum - 启用
GOPROXY=https://proxy.golang.org,direct可显著提速，避免因网络波动失败
为什么 CI 要固定 GOPROXY 和 GOSUMDB？
默认情况下，GOSUMDB 是 sum.golang.org，它要求联网校验 checksum；而某些内网 CI 环境无法访问外部服务，会导致 go build 卡住或失败。
常见组合配置：
立即学习“go语言免费学习笔记（深入）”；
env: GOPROXY: https://proxy.golang.org,direct GOSUMDB: sum.golang.org
若需离线或内网构建：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 设
GOSUMDB=off（不推荐，失去校验） - 更安全的做法是设
GOSUMDB=checksums.example.com并自建校验服务，或使用go mod verify在 CI 前手动校验 -
GOPROXY后加,direct是关键——当代理不可达时回退到直接拉取，避免整个流程中断
CI 中如何避免 go test 因模块缓存污染失败？
多个 Go 项目共用同一 runner 时，GOPATH/pkg/mod 缓存可能互相干扰，尤其当不同项目依赖同一模块的不同版本。典型现象是 go test 报错：「found modules in multiple major versions」或「require ...: version "v1.x" used for two different module paths」。
解决方式不是清全局缓存，而是让每个 job 隔离模块空间：
- 设置
GOMODCACHE=/tmp/modcache-$(date +%s)，每次构建用独立缓存目录 - 或更轻量：在
go test前加go clean -modcache（仅限单项目、低频 CI） - 注意：
go clean -modcache会清空所有模块，若并发 job 共享缓存则不可用
交叉编译 + 模块管理在 CI 中容易漏掉什么？
用 GOOS=linux GOARCH=amd64 go build 构建二进制时，如果项目含 cgo 依赖（如 net 包调用系统 DNS），CI 容器若没装 libc 头文件或 pkg-config，会静默降级为纯 Go 实现，行为可能和生产环境不一致。
关键检查点：
- 确认 CI 镜像是否含
build-essential（Debian/Ubuntu）或glibc-devel（CentOS/RHEL） - 若禁用 cgo（
CGO_ENABLED=0），需确保所有依赖都支持纯 Go 模式；例如github.com/mattn/go-sqlite3就不行 -
go list -m all可列出当前解析出的所有模块版本，适合在 CI 日志中输出用于事后审计
模块版本锁定靠的是 go.sum 和 go.mod，但真正生效的前提是：每次构建都从干净环境出发、不复用未经验证的缓存、且所有环境变量（尤其是 GOPROXY）保持一致。这点比写对某条命令更重要。
