Go模块版本锁定的关键在于严格执行go.mod与go.sum双文件契约：必须提交二者至Git、CI中运行go mod verify校验、禁用@latest、统一GOPROXY及GOPRIVATE配置，并杜绝手动修改或删除go.sum。
做不到“彻底规避”，但能用确定性手段让覆盖失效、让漂移不可发生。 依赖版本被覆盖，本质是 go.mod 没被当作契约执行，或 go.sum 被绕过校验。关键不是防人，而是堵住工具链里的漏洞。
go mod tidy 不提交 = 版本事实未锁定
很多人只在本地跑 go mod tidy，但没把生成的 go.mod 和 go.sum 提交进 Git —— 这等于没锁。其他人拉代码后执行 go build，Go 会按自己环境里缓存的模块版本去补全，结果可能和你本地不一致。
- 必须将
go.mod和go.sum同时纳入版本控制，且禁止在.gitignore中排除它们 - CI 流程中加一步
go mod verify，失败即中断构建 —— 它会校验go.sum中哈希是否匹配实际下载内容 - 开发者本地应配置
GOSUMDB=off或可信 sumdb（如sum.golang.org），避免因网络问题跳过校验
go get @latest 是最危险的快捷方式
用 go get example.com/lib@latest 看似省事，实则埋雷：latest 指向的是 tag 最新、或主分支 HEAD，它不固定。今天拉的是 v1.2.0，明天上游发了 v1.3.0，你再 go mod tidy 就自动升级，没人知道。
- 所有
go get必须显式带语义化版本，例如go get github.com/sirupsen/logrus@v1.9.3 - 团队应禁用
@latest：在 CI 中用grep -r '@latest' ./... || true扫描，发现即报错 - 升级依赖必须走 PR 流程，附带
go list -m -u输出和变更说明，由专人 Review
GOPROXY 设置不统一，等同于放弃版本一致性
有人用 https://proxy.golang.org，有人用 https://goproxy.cn，还有人设为 direct —— 这些代理对同一模块的版本索引、重定向逻辑不同，可能导致 go mod download 拉到不同 commit，哪怕版本号一样。
- 全团队强制统一
GOPROXY，推荐export GOPROXY=https://proxy.golang.org,direct - 私有模块必须配
GOPRIVATE，否则 Go 会试图走代理，导致 403 或 fallback 到direct，触发不可控行为 - IDEA / VS Code 的终端需继承系统级环境变量，避免 IDE 内置终端漏配
真正容易被忽略的点是：go.sum 不只是校验文件，它是信任锚点。一旦它被手动删掉、或被 go mod tidy -compat=1.17 这类兼容性参数干扰重写，整个版本锁定就形同虚设。别把它当“可再生”的临时文件 —— 它和 go.mod 一样，是团队间不可协商的合约文本。
