Go模块不兼容变更必须升级主版本号并创建新模块路径。官方定义的不兼容变更指破坏调用方正确行为，如删改导出项、结构体字段、函数签名、错误处理方式或接口方法集；兼容变更（如新增导出项、内部修改）可用小版本发布。标准做法是将v2+代码置于新路径如github.com/example/lib/v2，声明对应module名并打v2.0.0 tag，用户需显式更新导入路径。需避免在v1下打v2 tag、仅改module名不改导入路径、滥用replace/exclude等误区。可辅以迁移指南、双版本共存及短期兼容层提升用户体验。核心原则：路径即版本，版本即路径。
Go模块的不兼容变更，核心应对方式是**升级主版本号并创建新模块路径**。Go语言明确要求：一旦API发生不兼容修改（如函数签名删除、结构体字段移除、行为语义改变等），就不能在原模块路径下发布新版本，而必须通过v2+主版本号配合路径变更来隔离兼容性。
明确什么是“不兼容变更”
Go官方定义的不兼容变更，不只是“编译失败”，更关键的是**破坏已有调用方的正确行为**。例如：
- 删除或重命名导出的函数、方法、类型、变量、常量
- 修改导出结构体的公开字段（增删改类型/名字）
- 改变函数/方法的参数顺序、数量，或移除可选参数（即使有默认值逻辑）
- 将返回错误改为 panic，或将 panic 改为返回错误
- 修改公开接口的方法集（如添加/删除接口方法）
注意：仅修改内部实现、增加新导出项（如新增函数）、加注释、修复文档——这些都属于兼容变更，可用小版本（v1.2.3 → v1.2.4）发布。
标准做法：v2+ 路径升级
以模块 github.com/example/lib 为例，当需要做不兼容变更时：
- 将新代码放在 github.com/example/lib/v2 路径下（不是子目录，而是独立仓库路径）
- 在 go.mod 文件中声明模块名为 github.com/example/lib/v2
- 版本打 tag，如 v2.0.0（注意：v2.0.0 不是 v1.x 的延续，而是全新起点）
- 用户需显式替换导入路径：import "github.com/example/lib/v2"
Go工具链（go build、go get）会自动识别 /v2 后缀为独立模块，与 v1 并存，互不影响。
避免常见误区
- 不要在 v1 下发 v2.0.0 tag：这违反语义化版本约定，go 命令会拒绝解析
- 不要只改 go.mod 中的 module 名但不改导入路径：用户代码仍 import "github.com/example/lib"，会找不到符号
- 不要依赖 replace 或 exclude 强制“绕过”版本约束：这是临时调试手段，不能作为正式发布方案
- v2 模块无需保留 v1 的所有旧功能：它是独立演进的新模块，可精简、重构、重命名，只要自身 API 稳定即可
辅助策略：提供迁移指南与双版本共存期
对用户友好，可显著降低升级阻力：
- 在 README 或 /docs/migrate-v2.md 中列出关键变更点和替换写法（如 “Old: lib.Do() → New: libv2.Run()”）
- v1 版本保持维护一段时间（如只修严重 bug），标注 “v1 is in maintenance mode, please migrate to v2”
- 必要时，v2 可提供兼容层（如 github.com/example/lib/v2/compat），封装适配逻辑（但不推荐长期依赖）
基本上就这些。不复杂但容易忽略路径与版本号的绑定关系——记住：路径即版本，版本即路径。
