Go要求v2+模块在导入路径末尾显式添加/v2、/v3等后缀，根本原因是保证导入兼容性：相同路径必须完全向后兼容，而v2代表不兼容变更，故需不同路径区分；v1可省略版本号，但v2及以上必须显式声明，否则构建失败。
主版本路径规则是为了保证导入兼容性
Go 要求 v2+ 模块在路径末尾显式加上 /v2、/v3 等后缀，根本原因在于 Go 的导入兼容性规则：如果两个包的导入路径完全一样，它们就必须完全向后兼容。而 v2 代表不兼容的 breaking change，所以必须用不同的路径来区分。
v1 可以省略，但 v2 及以上必须显式声明
v0 和 v1 是特例，路径中不写主版本号是允许的（比如 github.com/user/lib 对应 v1.x）。但一旦发布 v2，路径就必须变成 github.com/user/lib/v2，否则 Go 工具链会直接报错——不是警告，而是拒绝构建。
-
go.mod中的module行要写成module github.com/user/lib/v2 - 所有
import语句也要用"github.com/user/lib/v2/pkg" -
go get安装时也得带路径后缀：go get github.com/user/lib/v2@v2.1.0
支持多版本共存，避免依赖冲突
路径带主版本号，让 Go 能在同一项目里安全地同时使用 v1 和 v2 两个不兼容版本。比如一个依赖用 v1，另一个用 v2，它们导入路径不同，不会互相覆盖或干扰。
- 没有这个规则，v2 更新就可能悄悄破坏 v1 的调用方
- 有了路径区分，每个版本都有独立的命名空间和类型系统
- 模块下载、缓存、校验都按完整路径隔离
这是 Go Modules 的强制约定，不是可选项
从 Go 1.11 引入 Modules 开始，这套规则就是硬性要求。它不是为了增加复杂度，而是用路径作为“契约标识”，把语义化版本（SemVer）真正落地到代码层面。只要路径变了，Go 就知道这是新世界，不会尝试做兼容性假设。
基本上就这些。
