^1.2.3 等价于 >=1.2.3 且
go.mod里写^1.2.3到底选哪个版本
它等价于>=1.2.3, ，不是“最新 patch”，也不是“自动升到 v1.2.9 就停”。Go 会从所有满足该范围的可用版本中，按 MVS（最小版本选择）原则挑一个——通常是满足条件的最低版本，但前提是它能同时满足其他所有依赖的约束。
常见错误是以为加了^就万事大吉，结果 CI 突然失败：某个间接依赖悄悄把github.com/some/lib拉到了v1.2.7，而这个版本内部改了一个未导出字段的结构体字段顺序，你的代码恰好用反射读取了它——语义化版本不保证这种隐式兼容，^也不兜底。
-
^1.2.3→ 允许v1.2.3到v1.999.999之间任意版本，只要主版本是v1 -
~1.2.3→ 更保守，只允许>=1.2.3, ，即锁定在<code>1.2.x分支 - 别写
latest或master：go mod 不认，会报invalid version: unknown revision master
为什么go get -u会升级你不想要的间接依赖
-u默认递归更新所有依赖到“满足当前约束的最新可能版本”，包括那些你没显式 require 的间接依赖。它不看你的意图，只看 MVS 能否选出更高版本——哪怕那个高版本只被某个二级依赖的一行require松散地指定了^1.0.0。
典型现象：本地go list -m all | grep some-pkg显示是v0.5.1，CI 上却跑出v0.6.0，因为某次go get -u顺手把另一个模块的golang.org/x/net从v0.14.0升到了v0.17.0，而这个新版又带进了some-pkg v0.6.0作为子依赖。
- 安全更新用
go get -u=patch，它只走~逻辑，升1.2.3 → 1.2.9，不跨.x - 查谁引入了某个包：
go mod graph | grep 'some-pkg' - 想锁死它？在
go.mod里加一行require some-pkg v0.5.1 // indirect，再go mod tidy
go list -m all才是真实生效版本的唯一权威
go.mod里写的require example.com/lib v1.2.0只是最低要求，不是最终版本。构建时真正加载的是 MVS 算出来的那个——可能更低（被其他依赖压着），也可能更高（被更强约束推着）。不信go.mod，也不信go get终端输出，只信go list -m all。
比如你刚go get example.com/lib@v1.2.0，go.mod也更新了，但运行 panic，一查go list -m all发现实际是v1.1.5。原因往往是另一个依赖（如github.com/xxx/yyy）只要求example.com/lib v1.1.0，MVS 就选了满足所有约束的最小版本v1.1.5（比v1.1.0新，但比v1.2.0旧）。
- 定位降级源头：
go mod graph | grep example.com/lib，看哪些模块在引用它，各自 require 的是什么版本 - 特别注意带
// indirect标记的行，它们常是静默降级的元凶 -
go list -m -versions example.com/lib可列出所有可用版本，帮你判断有没有更合适的候选
主版本升级必须改模块路径，否则v2.0.0不会被识别
Go 不会把github.com/user/lib v2.0.0当作github.com/user/lib的新版本——它只认路径。真正的 v2 必须显式声明模块路径为github.com/user/lib/v2，否则v2.0.0会被当成不合规标签，降级为伪版本（如v0.0.0-20250101000000-abc1234），甚至被忽略。
这意味着：如果 A 依赖lib v1.5.0，B 依赖lib/v2 v2.1.0，项目里就能同时存在两个独立模块；但如果 B 错误地写了require github.com/user/lib v2.1.0（没加/v2），Go 会拒绝解析，或强行用 v1 分支的某个兼容版本顶替，导致行为错乱。
- 发布 v2+ 版本时，必须同步更新
go.mod里的module指令，加上/v2后缀 - 导入时也必须用新路径：
import "github.com/user/lib/v2"，旧路径github.com/user/lib仍指向 v1 - 别指望 replace 或 exclude 能绕过这条规则——路径不匹配，模块系统根本不认
^1.0.0）悄然撬动整个依赖树，且这种撬动在go.mod里几乎不可见。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
