go允许同一库v1和v2共存，因其将github.com/user/lib/v2视为与github.com/user/lib完全不同的模块路径，v2+路径分隔是语义化版本兼容性的强制约定，不是可选项。
Go 语言本身没有“内核版本”概念，你实际想问的是：当项目中多个模块依赖同一库的不同 major 版本（如 v1 和 v2）时，如何让它们共存且不冲突。
为什么 go mod 允许同一库的 v1 和 v2 同时存在
因为 Go 把 github.com/user/lib/v2 视为与 github.com/user/lib 完全不同的模块路径——v2+ 的路径分隔是语义化版本兼容性的强制约定，不是可选项。只要发布方按规范把 v2.0.0 放在 /v2 子路径下，Go 就不会尝试“升级”或“降级”，而是并行加载两个独立模块。
- 常见错误现象：
go build报错cannot find module providing package github.com/user/lib/v2，其实是没在go.mod中显式require该路径 - 使用场景：主模块用
v1，引入的第三方工具内部用了v2，两者 API 不兼容但互不调用 - 关键点：必须在
go.mod中分别声明，例如：require ( github.com/user/lib v1.5.0 github.com/user/lib/v2 v2.3.0 )
go list -m all 显示重复模块名就说明多版本已生效
go list -m all 是验证是否真有多版本共存的最直接方式。如果输出里同时出现 github.com/user/lib v1.5.0 和 github.com/user/lib/v2 v2.3.0，说明 Go 已成功解析并保留了两个版本。
- 注意：它不会显示
github.com/user/lib v2.3.0——v2 版本的模块路径一定是带/v2后缀的，否则就是发布不合规 - 如果只看到一个版本，可能是间接依赖被统一升级了，用
go list -m -graph查依赖源头 - 性能影响几乎为零：Go 编译器只编译实际 import 的包，
v1和v2的代码完全隔离，无运行时开销
replace 指令不能跨 major 版本混用
replace 只能映射到同一模块路径的其他版本，比如把 github.com/user/lib v1.5.0 替换成本地 ../lib；但它不能把 github.com/user/lib/v2 替换成 github.com/user/lib，因为路径不匹配，go mod tidy 会直接报错。
- 典型错误：
replace github.com/user/lib/v2 => ./lib失败，提示replaced module must have same major version - 正确做法：若要本地调试 v2，必须确保
./lib目录下有go.mod，且其module声明为github.com/user/lib/v2 - 容易踩的坑：误以为
replace能绕过路径约束，结果编译失败或运行时 panic
真正需要警惕的不是“能否共存”，而是模块发布方是否严格遵循了 /v2 路径规则——只要有一方没照做，整个多版本逻辑就会崩塌。检查每个依赖的 go.mod 文件，确认 major 版本号已体现在模块路径中，比任何工具配置都重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
