go list -m -versions仅查询远程仓库公开tag列表，不下载或解析依赖；gorelease分析api变更（新增/删除/修改导出符号）；github compare链接可快速浏览代码差异，三者需组合验证版本升级影响。
用 go list -m -versions 查看可用版本列表
这是最轻量的起点：不下载、不解析依赖图，只查远程模块仓库（如 proxy.golang.org）公开的 tag 列表。执行后会输出类似 v1.2.0、v1.2.1、v1.3.0 的有序列表，按语义化版本规则排序。
注意它不保证所有版本都可用——有些 tag 可能被 retract（撤回），或因网络策略不可达。若需确认某个版本是否存在，可手动 curl：curl -I https://proxy.golang.org/github.com/user/repo/@v/v1.3.0.info，状态码 200 表示存在。
用 gorelease 分析 API 级别变更
真正影响代码兼容性的不是版本号本身，而是导出符号（函数、类型、方法）的增删改。直接读 GitHub diff 容易漏掉重命名、签名变化等细节。gorelease 是专为此设计的工具：
- 安装：
go install github.com/google/go-mods/cmd/gorelease@latest - 比对两个版本：
gorelease -base=v1.2.0 -target=v1.3.0 github.com/user/repo - 输出包含：新增/删除/修改的导出标识符、是否破坏向后兼容、是否引入新依赖
它依赖模块的 go.mod 和源码结构，所以必须确保目标模块已发布且含完整元信息；私有模块需先 go mod download 或配置 GOPRIVATE。
用 GitHub compare URL 快速看代码差异
当需要快速确认某次升级是否只修 bug、是否含文档或测试变更时，人工扫 diff 更高效。Go 模块 tag 通常对应 Git commit，构造 compare 链接即可：
格式为：https://github.com/user/repo/compare/v1.2.0...v1.3.0（注意是 ...，不是 ..）
常见陷阱：
- 模块未按规范打 tag（比如写成
1.2.0而非v1.2.0），链接会 404 - v2+ 版本路径变更（如
github.com/user/repo/v2），需单独构造其 own compare 链接 - 某些组织用 release 分支而非 tag，此时应比对分支名，如
main...v1.3
为什么不用 go mod graph 做版本差异对比
go mod graph 显示的是当前构建中“实际选中的版本关系”，不是“两个版本之间的差异”。它适合定位谁拉入了哪个版本，但无法告诉你 v1.2.0 → v1.3.0 新增了什么接口。
容易混淆的点：
- 运行
go mod graph | grep pkg只能看到路径和版本号，看不出 API 是否兼容 - 如果模块在
go.sum中有多个校验和条目，说明项目里确实加载了多版本——但这属于依赖冲突诊断范畴，不是版本差异分析 - 想看“如果升级到 v1.3.0，我的代码会不会编译失败”，得先
go get pkg@v1.3.0+go build，而不是只看 graph
版本差异的本质是契约变更，不是拓扑结构。工具链里没有“一键 diff 两个版本所有行为”的银弹，得组合用 gorelease（API）、GitHub compare（代码）、go test（运行时）三者交叉验证。
