因为Go将v1和v2视为完全独立模块，主版本号不同必须通过路径后缀（如/v2）显式区分，路径不同即命名空间隔离，各自拥有独立go.mod、依赖树和类型系统，无法共享接口或结构体。
为什么v1和v2会被当成两个不同模块
Go 不把 v1 和 v2 当作同一模块的升级，而是当作完全独立的模块——这是语义化版本在 Go 模块系统里的硬性规则。只要主版本号不同，导入路径就必须带后缀，比如 github.com/user/pkg 和 github.com/user/pkg/v2 在 Go 看来是两个无关模块，各自维护自己的 go.mod 和依赖树。
常见错误现象：你执行 go get github.com/user/pkg@v2.0.0，但代码里仍写 import "github.com/user/pkg"，结果编译报错说找不到符号，或运行时 panic，因为实际加载的是 v1 版本，而 v2 的 API 已不兼容。
- 必须同步改两处：代码里的
import路径 +go.mod中的require行 - 如果旧代码大量使用 v1 接口，直接切 v2 往往需要重写逻辑，不是简单替换版本号
- v2 模块的
go.mod文件里模块路径必须声明为module github.com/user/pkg/v2，否则 Go 不认
如何安全升级到新主版本（如 v2 → v3）
升级主版本不是“更新一个数字”，而是重构依赖关系链。核心动作是让所有依赖它的模块都切换到新路径，否则会形成 v1/v2/v3 多版本共存，且无法共享类型或接口。
实操步骤：
立即学习“go语言免费学习笔记（深入）”；
- 先确认目标模块是否已发布带版本后缀的 tag，例如
v2.0.0对应路径github.com/user/pkg/v2 - 用
go list -m all | grep user/pkg查当前项目里实际用了几个版本；若输出含github.com/user/pkg和github.com/user/pkg/v2两行，说明已混用 - 逐个修改 import：把
"github.com/user/pkg"替成"github.com/user/pkg/v2"，并适配 API 变更（比如函数签名、返回值、struct 字段） - 运行
go mod tidy，它会自动更新go.mod中的require行，并删掉旧路径的残留 - CI 中务必加
go build ./...，防止某处漏改 import 导致构建失败
replace 不能绕过主版本路径约束
replace 是个常见误区：有人试图用 replace github.com/user/pkg => github.com/user/pkg/v2 v2.0.0 强制统一，但这根本无效——Go 在解析 import 时只看路径字符串，replace 不会重写 import 语句本身。
真正生效的前提只有一个：你的代码里 import 的路径必须和 replace 左侧完全一致。如果 import 是 "github.com/user/pkg"，那 replace github.com/user/pkg/v2 => ... 就永远不会触发。
- 想用
replace调试 v2 分支？得先改 import 到/v2，再写replace github.com/user/pkg/v2 => ./local-v2 - 本地调试完要上线前，必须删掉
replace行，否则 CI 构建可能因 GOPROXY 差异拉不到本地路径 - 用
go list -m all验证：生效的 replace 会在输出中显示=> ./local-v2或对应 fork 地址
多版本共存不是 bug，但需警惕隐式类型不兼容
Go 允许 github.com/user/pkg 和 github.com/user/pkg/v2 同时存在，每个模块只感知自己 require 的那个。表面看没问题，但一旦跨模块传递结构体、接口或调用函数，就会暴露类型不兼容。
典型问题场景：
- 你的 main 包 import
v2，但某个第三方库（如github.com/other/tool）内部 importv1，然后你把它返回的 struct 传给 v2 的函数——编译失败 - mock 测试中伪造了 v1 版本的 interface，却试图赋值给 v2 定义的变量——类型不匹配
-
go.sum里出现同一仓库多个校验和（如github.com/user/pkg@v1.5.0和github.com/user/pkg/v2@v2.1.0），说明确实加载了两个版本
真正麻烦的不是多版本本身，而是它们在边界处悄悄破坏类型一致性。排查时别只盯 go.mod，重点看 go mod graph 输出里谁引入了哪个路径，再结合实际 import 位置判断是否越界使用。
