运行 go list -m all 可查看当前项目实际使用的模块版本，它展示经最小版本选择（MVS）算法计算后的最终选定版本；go list -m -u all 还可标出有更新可用的模块。
Go模块版本号直接看 go.mod 文件里的 require 行，但真正生效的版本由 Go 工具链根据语义化规则自动解析并锁定——不是你写啥就用啥，而是它算出来一个满足所有依赖约束的最小兼容版本。
怎么看当前项目实际使用的模块版本？
运行 go list -m all 是最准的方式，它展示整个依赖图中每个模块**最终被选中的版本**（经最小版本选择 MVS 算法计算后），而非 go.mod 中声明的“意向版本”。
- 如果某模块在
go.mod里写的是v1.2.3，但另一个依赖要求>= v1.5.0，go list -m all显示的可能是v1.5.0或更高 -
go list -m -u all可额外标出哪些模块有更新可用（即本地版本 - 注意：
go mod graph能看到谁依赖了谁，但不显示具体版本；要查某模块被谁以什么版本引入，得配合go list -m -f '{{.Path}} {{.Version}}' example.com/pkg
为什么 go.mod 里写的版本号不等于实际使用版本？
因为 Go 使用最小版本选择（MVS）算法，目标是选一个能同时满足所有依赖约束的语义序最小版本，而不是最新或你手动指定的那个。
- 例如 A 模块 require
github.com/foo/bar v1.8.0，B 模块 requiregithub.com/foo/bar v1.2.0，C 模块 requiregithub.com/foo/bar v1.9.0→ 实际选用v1.9.0（因v1.2.0不满足 A 和 C 的最低要求） - 写
v1.2.x或v1.2.0在go.mod中只是约束下限，Go 会自动升到满足所有条件的最小合法版本 - 想强制锁死某个版本？必须用
go get example.com/pkg@v1.2.3+go mod tidy，否则下次go get -u可能悄悄升级
v2+ 版本路径必须带 /v2 后缀，否则会报错
这是 Go 强制的语义导入版本控制（Semantic Import Versioning）规则：主版本 ≥ 2 时，模块路径和 import 语句都必须显式包含 /vN，否则工具链无法区分 v1 和 v2 共存。
- 错误写法：
require github.com/some/pkg v2.1.0+import "github.com/some/pkg"→ 构建失败，提示 “module declares its path as: github.com/some/pkg/v2” - 正确写法：
require github.com/some/pkg/v2 v2.1.0+import "github.com/some/pkg/v2" - 发布 v2 版本前，必须先改
go.mod第一行module github.com/some/pkg/v2，再打 tagv2.1.0，否则go get会拉不到
预发布、伪版本、v0 版本怎么识别和处理？
它们在 go list -m all 输出中很常见，但含义差异大，容易误判稳定性：
-
v0.0.0-20240512102345-abcdef123456：伪版本，表示未打 tag 的 commit，仅用于临时调试，不可用于生产 -
v1.2.3-beta.1或v1.2.3-rc.2：预发布版本，语义上仍属 v1.2.3，但 API 可能变动，CI 中建议禁用@latest自动拉取 -
v0.12.0：开发中版本，无向后兼容保证，升级需人工验证，不建议在关键服务中长期使用
真正稳定的信号只有 v1.x.y（且 y ≥ 0）或明确标注为 stable 的 release note —— 其他都得自己多看 CHANGELOG 和测试覆盖。
