go模块版本遵循语义化规则：v2+必须加/v2后缀以区分兼容性边界，路径与版本号共同决定加载行为；@latest不跨主版本升级，MVS算法选满足所有约束的最小语义版本；预发布版默认被忽略，生产环境禁用。
Go 模块版本不是“随便写个数字”，而是有强制语义约束的规则系统：写错版本号、漏掉 /v2 后缀、误用 @latest，轻则 go build 报错 cannot find module providing package，重则线上行为突变。核心就一条：版本号决定兼容性边界，路径决定能否加载。
为什么 v2+ 必须加 /v2 后缀？
这不是风格问题，是 Go 工具链硬性要求——没有 /v2，它根本不会去查 v2 的代码。
- v1 版本导入路径是
"github.com/user/lib"，对应go.mod中module github.com/user/lib - v2 版本必须改两处：
–go.mod的module行变成module github.com/user/lib/v2
– 所有import语句变成import "github.com/user/lib/v2" - 漏掉任一环节，编译时直接报错：
build failed: cannot load github.com/user/lib: module github.com/user/lib@latest found (v2.1.0+incompatible), but does not contain package github.com/user/lib
go get 后面跟 @v1.9.0 和 @latest 有什么区别？
区别在于“兼容范围”和“升级意图”：
-
go get example.com/pkg@v1.9.0→ 精确锁定，go.mod写入require example.com/pkg v1.9.0，后续go mod tidy不会动它 -
go get example.com/pkg@latest→ 实际取的是当前主版本下最新稳定版（如 v1.12.3），但**绝不会跨主版本升到 v2.x**；如果该模块已发布 v2，而你没改 import 路径，@latest仍只会拉 v1.x 最新版 - ⚠️ 风险点：
@latest在 CI 中可能因远程仓库新增 patch 版本导致构建结果不一致，生产环境应避免
为什么 go mod tidy 有时降级了依赖版本？
因为它执行的是“最小版本选择（MVS）”，不是“选最新”。它找的是满足所有依赖约束的**语义序最小版本**。
立即学习“go语言免费学习笔记（深入）”；
- A 模块 require
github.com/pkg/log v1.5.0
B 模块 requiregithub.com/pkg/log v1.8.0
C 模块 requiregithub.com/pkg/log v1.2.0
→ MVS 选v1.8.0（因为v1.2.0不满足 A 的最低要求） - 但如果 A 改成 require
github.com/pkg/log v1.10.0，而 B 仍锁在v1.8.0，go mod tidy反而可能把整个项目降到v1.10.0—— 因为这是唯一同时满足 A（≥1.10.0）和 B（≥1.8.0）的最小版本 - 验证方式：
go list -m all | grep pkg/log查看最终选定版本；go mod graph | grep pkg/log查谁在拉哪个版本
打 Git 标签时，v2.0.0 和 v2.0.0-beta.1 能被正常引用吗？
能，但行为完全不同：
-
v2.0.0是正式版，会被go get @latest或go list -m -versions列出，且默认参与 MVS 计算 -
v2.0.0-beta.1属于预发布版本（pre-release），Go 默认**忽略它**：go get @latest不会选它，go list -m -versions默认也不显示（需加-json才能看到） - 若真要使用预发布版，必须显式指定：
go get example.com/pkg@v2.0.0-beta.1，且你的go.mod中必须已存在/v2路径声明 - ⚠️ 生产环境严禁依赖 pre-release 版本：无 SLA、无兼容性保证、随时可能被删
最常被忽略的一点：语义化版本不是“人看的注释”，而是 Go 构建系统的输入信号。写 v2.0.0 就意味着你承诺了不兼容变更，并主动承担路径更新、用户迁移、测试覆盖的全部成本——工具不会提醒你“这个改动其实兼容”，它只认版本号字面含义。