go.mod 和 go.sum 必须一同提交至 Git，二者缺一不可；GO111MODULE=on 须全局启用；依赖升级需显式指定语义化版本并运行 go mod tidy；GOPROXY 和 GOPRIVATE 必须全团队统一配置。
go.mod 和 go.sum 必须一起提交 Git
不提交 go.sum 就等于放弃依赖一致性保障。它不是“可选校验文件”，而是构建可重现性的强制凭证——哪怕团队所有成员都用同一份 go.mod，只要有人本地没生成或漏提 go.sum，CI 构建就可能拉到不同哈希的包，导致运行时行为差异甚至 panic。
常见错误现象：go build 在本地成功，CI 报错 verifying github.com/some/pkg@v1.2.3: checksum mismatch；或者不同人 go mod download 后 go list -m all 显示相同模块却有不同伪版本（如 v0.0.0-20230101000000-abc vs v0.0.0-20230102000000-def）。
- 所有成员必须把
go.mod和go.sum都加入 Git 跟踪，禁止 .gitignore 过滤它们 - CI 流水线开头加
go mod verify，失败即中止，不给“侥幸通过”机会 - 如果
go.sum出现冲突，不要手动编辑，而是统一执行go mod download后重新生成
GO111MODULE=on 是硬性前提
设成 auto 或留空，在团队混合使用 GOPATH 项目或旧脚本时极易触发非预期行为：比如某人在 $GOPATH/src 下新建项目，go get 会静默走 GOPATH 模式，go.mod 不生成，后续协作直接断裂。
正确做法是全局启用，避免路径依赖判断：
立即学习“go语言免费学习笔记（深入）”；
- 所有开发者执行
go env -w GO111MODULE=on - CI 环境在 job 开头显式设置
export GO111MODULE=on - 检查是否生效：运行
go env GO111MODULE输出必须是on，不是auto
依赖升级必须用 go get module@version 显式指定
用 go get -u 或 go get latest 是团队协作中最常见的版本漂移源头。它不保证语义化兼容性，可能把 v1.2.0 升到 v1.3.0（含 breaking change），而 go.mod 里只记了 v1.3.0，没人知道这个版本是否被测试过。
真正可控的升级方式：
- 升级前先查可用版本：
go list -m -versions github.com/gin-gonic/gin - 明确指定带
v前缀的语义化版本：go get github.com/gin-gonic/gin@v1.9.1 - 升级后立即运行
go mod tidy，确保go.sum更新且无冗余依赖 - 禁止在 CI 中执行任何
go get -u类命令
GOPROXY 必须统一配置，私有模块走 GOPRIVATE
依赖下载失败不是“网络问题”，而是团队环境不一致的信号。有人用默认代理，有人直连，有人配了内部 Athens，结果同样 go mod download 在不同机器上拉取的模块来源、缓存、甚至内容都可能不同。
关键约束点：
- 全团队统一设置：
export GOPROXY=https://proxy.golang.org,direct - 涉及公司内网模块时，必须配置
GOPRIVATE=git.company.com，否则direct会跳过代理直连失败 - CI 环境变量应与本地完全一致，不能靠“默认值”侥幸
- 验证方式：执行
go env GOPROXY GOPRIVATE，输出必须和文档规定一致
真正难的不是命令怎么敲，而是所有人对同一套规则保持零容忍——比如某人临时改了 GO111MODULE=auto 调试旧项目，忘了切回来，顺手提交了一个没 go.mod 的 PR，整个流水线就卡在依赖解析阶段。约束本身简单，执行链上的每个环节都得咬住不松口。
