/v2必须写入模块路径，因为Go仅通过导入路径区分兼容性，同一路径下v1.9与v2.0共存会导致编译错误或类型不匹配；github.com/user/lib/v2与github.com/user/lib被视为完全独立模块，路径隔离是实现向后兼容的前提。
Go 模块大版本向后兼容不是靠“尽量不改”实现的，而是靠路径隔离 + 语义约束 + 工具验证三者硬性配合。不改模块路径、不加 /v2 后缀，就等于放弃兼容性控制权——Go 会强行统一版本，最终大概率编译失败或运行时 panic。
为什么 /v2 必须写进模块路径
Go 不靠版本号区分兼容性，只认导入路径。同一路径下 v1.9 和 v2.0 的包如果共存，go build 会报错：duplicate import 或直接选高版本导致类型不匹配。
-
github.com/user/lib是 v1 路径；github.com/user/lib/v2才是合法 v2 路径，二者在 Go 看来是完全独立的模块 - 没加
/v2却打了 v2.0.0 tag，Go 仍按 v1 解析，后续所有 v2+ 版本都会被降级为 v1.x（通过go list -m all可验证） - gopkg.in 是例外：它强制要求
gopkg.in/yaml.v2这种点号后缀，不是斜杠，否则解析失败
go.mod 里怎么声明 v2+ 模块才有效
主模块引用 v2+ 依赖时，require 行必须显式带路径后缀，否则 Go 不识别为新模块。
- 正确写法：
require github.com/user/lib/v2 v2.1.0 - 错误写法：
require github.com/user/lib v2.1.0—— 这会被当作 v1.x 的非法版本号，go mod tidy会报invalid version - 如果你是模块作者，发布 v2 时
go.mod第一行也得改：module github.com/user/lib/v2，否则下游无法正确 require
真正决定兼容性的不是代码，是 go list -m all 和 go mod graph
写完代码、改完路径、打完 tag，不代表就安全了。必须验证构建图是否真把 v1 和 v2 当作两个模块加载。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go list -m all | grep lib，应同时看到github.com/user/lib v1.5.0和github.com/user/lib/v2 v2.1.0 - 用
go mod graph | grep lib查谁拉了哪个版本：如果某依赖偷偷require github.com/user/lib v1.9.0，而你主模块 require/v2，那没问题；但如果它 requiregithub.com/user/lib v2.0.0（没后缀），就会触发冲突 - CI 中必须跑
go build ./...而非仅go build ./cmd/xxx，否则子模块里的 v1/v2 混用可能被漏掉
最容易被忽略的点：v2 模块的内部 import 语句也得同步改。比如 github.com/user/lib/v2 里的代码如果还写 import "github.com/user/lib"，编译直接失败——它必须写成 import "github.com/user/lib/v2"。这个细节不检查，本地能跑，CI 会卡在第一行 import 上。
