Go项目无“统一版本”目标，只追求可复现构建：须由go get或go mod tidy驱动更新go.mod与go.sum，手动改版本号无效；v2+模块必须带/v2路径；go.sum必须提交Git，忽略将导致构建不可信。
Go 项目里没有“统一版本”这个操作目标，只有“可复现构建”——靠 go.mod 和 go.sum 共同锁定，而不是靠人工对齐所有依赖的版本号。
直接改 go.mod 里的版本号没用
手动把 require github.com/sirupsen/logrus v1.8.0 改成 v1.9.3，不会触发下载，也不会更新 go.sum。下次执行 go build 或 go mod tidy，Go 会按原有解析逻辑重新计算版本，很可能又回退或跳升。
- 真正生效的操作必须由 Go 命令驱动：比如
go get github.com/sirupsen/logrus@v1.9.3 - 该命令会拉取包、更新
go.mod中的require行、追加/更新go.sum校验和 - 如果模块有间接依赖冲突，命令会报错并中止，而不是静默覆盖
go get -u 不等于“统一”，它只升不降
go get -u 默认升级到满足当前约束的最新 minor/patch 版本（如从 v1.8.0 → v1.8.5），但不会跨 major（比如不从 v1.x 升到 v2.x）。它也不保证所有依赖都升到同一版本，只是各自找兼容上限。
- 想批量升级全部直接依赖：用
go get -u ./...（注意末尾...） - 想强制降级某个包：必须显式指定，如
go get github.com/sirupsen/logrus@v1.7.0 - 升级后务必运行
go mod tidy，清理未引用的require行，并补全缺失的间接依赖声明
v2+ 模块必须带 /v2 路径，否则无法共存
如果你的项目同时被 pkgA（要求 github.com/user/lib v1.5.0）和 pkgB（要求 github.com/user/lib v2.3.0）依赖，Go 不会自动“统一”成一个版本——它会报错，因为 v2 没走 Go 的模块路径规则。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法是：发布
v2.3.0时，模块声明必须是module github.com/user/lib/v2 - 所有导入语句也必须写成
import "github.com/user/lib/v2" - 这样
v1和v2就是两个独立模块，可同时存在于项目中 - 别指望
go mod tidy自动帮你加/v2，那是模块作者的责任
go.sum 被忽略 = 构建不可信
很多团队把 go.sum 加进 .gitignore，以为“反正能自动生成”。这是高危操作：一旦 CI 或新成员拉代码后执行 go build，可能从不同镜像源拉到同 tag 但内容不同的 zip 包（比如被篡改或缓存污染），而 go.sum 缺失就完全无法校验。
-
go.sum必须提交到 Git，且 CI 流程应检查其变更：如果它变了，说明依赖图有实质变动，需人工确认 - 禁用
GOPROXYfallback（例如设为GOPROXY=https://goproxy.cn,direct），避免代理找不到时悄悄切到direct并拉取意外版本 - 私有模块要配置
GO_PRIVATE，防止被公共 proxy 重定向导致校验失败
真正难的不是“怎么锁”，而是理解 Go Modules 的约束前提：模块路径即版本标识、go.sum 是校验快照而非锁文件、replace 不传递给下游、多 go.mod 目录之间无全局版本联动。这些细节一旦漏掉，再勤快地 go mod tidy 也救不回构建一致性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
