Go版本选择需遵循SemVer和MVS算法，优先PATCH升级，MINOR升级须全量测试；v2+版本必须路径含/v2且import同步更新；replace/exclude仅限临时调试，统一版本应显式require后tidy。
别用 @latest 直接升级，它不等于“最稳”，而可能是破坏兼容性的次版本跳变。
怎么判断该用 v1.5.0 还是 v1.6.2
Go 的版本选择不是“最新就好”，而是由语义化版本（SemVer）和最小版本选择（MVS）算法共同决定的。你写 go get github.com/some/pkg@v1.6.2，Go 会检查所有直接/间接依赖对这个模块的约束，最终选一个满足全部条件的最低版本——不一定是 v1.6.2，除非它是唯一解。
- 先运行
go list -m -versions github.com/some/pkg看有哪些可用版本，注意避开v0.x（不稳定）和带-beta/-rc的预发布版 - 重点看 CHANGELOG：v1.6.0 是否新增了你要的功能？v1.6.2 是不是只修了 panic 或竞态 bug？
- 用
go mod graph | grep some/pkg查谁在拉这个包、拉的是哪个版本，避免被某个老旧子依赖悄悄降级 - 如果项目已上线，优先选 PATCH 升级（如 v1.5.0 → v1.5.3），MINOR 升级（v1.5 → v1.6）务必跑一遍
go test ./...
为什么 v2 版本要写成 /v2 路径
Go 不允许同一模块路径（如 github.com/user/lib）同时存在 v1 和 v2——它不是按版本号隔离，而是按模块路径隔离。如果你看到别人用了 github.com/user/lib/v2，那是因为作者遵守了 Go 的 major 版本路径规范；否则，go get github.com/user/lib@v2.0.0 会被当作非法操作拒绝，或导致构建失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 没加
/v2的 v2+ 发布，Go 会当成伪版本（如v0.0.0-20240101-abcd123），无法被正常 require - 你自己发 v2 版本时，必须改
go.mod第一行：从module github.com/user/lib改成module github.com/user/lib/v2 - 下游用户升级到 v2，代码里 import 路径也得同步改成
"github.com/user/lib/v2"，这是硬性要求，不是可选项
replace 和 exclude 不是万能解药
replace 能临时绕过官方版本，但只应在调试或紧急修复时用；exclude 更危险——它删的是整个模块的某版本，但若其他依赖强依赖那个版本，go build 会直接报错“missing required module”。
立即学习“go语言免费学习笔记（深入）”；
- 本地调试用
replace github.com/old/pkg => ./pkg-fix可以，但提交前必须删掉，或改用//go:build ignore注释隔离 - 想统一版本，正确做法是：在
go.mod中显式require github.com/old/pkg v1.8.0，再跑go mod tidy -
exclude基本只用于剔除已被废弃、且没人真正调用的旧版间接依赖（极少见），99% 的“冲突”其实该靠升级上游依赖来解决 - CI 中一定要加
go list -m all | grep pkgname校验实际解析版本，别信go.mod里写的
最容易被忽略的点：MVS 算法选出来的“最小版本”，可能比你本地测试的版本低——因为某个你没注意的间接依赖锁死了 v1.4.0。上线前务必用 go mod graph 和 go list -m all 对照着看真实依赖树，而不是只盯着 go.mod 文件。
