Go模块v2+必须加/v2路径后缀，因工具链将example.com/pkg/v2与example.com/pkg视为独立模块以解决钻石依赖，否则报invalid version错误；路径后缀是版本识别唯一依据，且go get等命令受MVS算法约束。
Go模块依赖管理中，语义化版本不是可选规范，而是强制约束——所有合法模块版本必须符合 vX.Y.Z 格式，否则 go mod 拒绝解析或报错。
为什么 v2 及以上主版本必须加 /v2 路径后缀
Go 不把 example.com/pkg/v2 和 example.com/pkg 当作同一个模块，而是视为两个完全独立的模块。这是为了解决“钻石依赖”中不同主版本共存的问题。
- 如果不加
/v2，Go 会报错：invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2 - 即使你本地改了
go.mod中的module行，没同步更新所有import语句，编译时仍会提示cannot find module providing package - 路径后缀是 Go 工具链识别主版本的唯一依据，
go get、go list、go mod graph全部依赖它
go get 指定版本时的常见陷阱
运行 go get example.com/pkg@v1.5.0 看似简单，但实际行为受当前 go.mod 约束和 MVS（最小版本选择）算法影响，并非“直接切到该版本”。
- 如果已有依赖要求
example.com/pkg >= v1.6.0，go get @v1.5.0会被忽略，最终选的是满足所有约束的最低兼容版本 - 使用伪版本（如
v0.0.0-20240512103022-abcdef123456）时，必须确保 commit 存在且未被 force push 覆盖，否则go mod download失败 -
go get -u默认只升级到最新MINOR版本（如从v1.2.0升到v1.3.0），不会跨MAJOR—— 想升v2必须显式写@v2.0.0并处理路径变更
go.sum 文件里哈希值失效的典型场景
go.sum 记录每个模块版本的校验和，用于验证下载内容完整性。但它不是“一次写入永久有效”的快照。
立即学习“go语言免费学习笔记（深入）”；
- 当你用
go get引入新版本，或执行go mod tidy，go.sum会自动追加新条目，但旧条目不会自动删除 - 如果上游模块作者重写了 tag（比如
v1.2.0对应的 commit 被 force push），你本地go.sum中的哈希就失效，下次go build会报错：verifying example.com/pkg@v1.2.0: checksum mismatch - 手动编辑
go.sum极易出错；正确做法是删掉对应行，再运行go mod download example.com/pkg@v1.2.0重新生成
预发布版本（如 v1.0.0-beta.1）为什么默认不被选用
Go 的版本排序规则把带预发布标签的版本视为“比同名正式版更旧”，所以 v1.0.0-beta.1 v1.0.0，而 v1.0.0 又 v1.0.1。
- 这意味着：如果你的
go.mod写了require example.com/pkg v1.0.0，go mod tidy不会降级到beta版，也不会自动升到v1.0.1—— 它严格锁定v1.0.0 - 想用 beta 版，必须显式指定：
go get example.com/pkg@v1.0.0-beta.1，否则go list -m all里根本看不到它 - CI/CD 流程中若误引入预发布版本，
go.sum会记录其哈希，但上线前务必检查是否含-beta、-rc等字样，生产环境应禁止这类版本出现在go.mod
真正容易被忽略的不是语义化版本本身，而是它和 Go 工具链深度耦合的隐式行为：路径后缀决定模块身份、MVS 算法覆盖人工指定、go.sum 哈希绑定的是 commit 而非 tag 名字——这些细节一旦出错，往往表现为“本地能跑，CI 报错”或“同事拉代码编译失败”。
