Go要求模块版本号必须符合SemVer规范且强制带v前缀，v2+主版本需在导入路径中显式添加/v2后缀，否则编译失败；go get不带v会触发伪版本生成；go.sum中+v1.2.0+incompatible表示该模块未合规使用Go Modules。
Go 的语义化版本（SemVer）不是可选配置，而是模块机制的硬性要求——所有 go.mod 中的依赖版本号必须带 v 前缀，且格式为 vMAJOR.MINOR.PATCH；不合规的版本号会导致 go build 或 go mod tidy 直接报错。
为什么 go get github.com/user/pkg@1.2.0 会失败
Go 工具链强制要求版本标识以 v 开头。写成 1.2.0 会被解析为“无版本标签的 commit”，触发伪版本生成逻辑（如 v0.0.0-20250101000000-abcdef123456），而非你预期的正式发布版。
- 正确写法必须是：
go get github.com/user/pkg@v1.2.0 - 如果该 tag 不存在，Go 会报错：
unrecognized import path或invalid version - 使用
@latest时，Go 仍会解析出带v的真实版本（如v1.5.3），不会跳过 SemVer 校验
require 里写 v2 但代码没改 import 路径，为什么编译不过
Go 将主版本 ≥2 的模块视为独立路径： github.com/user/pkg/v2 和 github.com/user/pkg 是两个完全无关的模块，类型、函数、变量零共享。
- 仅在
go.mod的require中升级到v2不够，必须同步修改所有import语句为"github.com/user/pkg/v2" - 否则编译器报错：
cannot find package "github.com/user/pkg" in any of...（因为v2模块不提供/v2以外的导入路径） - 没有自动重定向或兼容层——v2 不是 v1 的“增强版”，而是全新模块
怎么查清谁把 v3 引进来的
依赖树中某间接模块突然升到不兼容主版本，往往是因为某个上游模块悄悄切到了 /v3 路径，而你的代码还按旧路径调用。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
go mod graph | grep 'pkg/v3'快速定位引入者（例如输出myapp github.com/other/lib@v1.8.0） - 再查具体依赖链：
go mod graph | grep 'other/lib' | head -5 - 比翻
go.mod更可靠，因为go.mod只显式列出直接依赖，graph展示完整传递关系 - 确认后，要么升级调用方代码适配
/v3API，要么用replace临时锁定旧版（仅限调试）
go.sum 里出现多个 v1.2.0 和 v1.2.0+incompatible 是什么情况
+incompatible 表示该模块未声明 go.mod，或虽有 go.mod 但主版本号为 v0 或 v1 且未遵守 SemVer 规则（比如打了 v1.2.0 tag 却含破坏性变更）。
- Go 会将这类模块标记为
incompatible，并在go.sum中单独记录其校验和 - 同一模块路径下出现
v1.2.0和v1.2.0+incompatible，说明项目同时依赖了“规范发布版”和“非规范提交”，极可能引发运行时 panic - 解决方式：优先迁移到明确支持 Go Modules 且打正规
vX.Y.Ztag 的版本；若无法替换，需在go.mod中用replace统一指向可信源
真正容易被忽略的是：语义化版本的约束力不在开发者手里，而在 Go 工具链的解析规则中。你改不了 import 路径却想用 v2，或者漏掉 v 前缀指望它“自动补全”，都会在 go build 那一刻才暴露——没有灰色地带，只有合法或拒绝。
