go get -u 更新后 build 失败大概率是 minor 版本不兼容，因某些库在 minor 升级中擅自修改导出 API（如删字段、改函数签名），未升主版本却破坏兼容性，需用 go list -m -versions 和 go doc 对比验证。
go get -u 更新后 build 失败，大概率是 minor 版本不兼容
Go 的 go get -u 默认升级到最新 次要版本（如从 v1.2.3 → v1.3.0），但某些库在 minor 升级时偷偷改了导出 API —— 比如删掉一个字段、调整函数参数顺序、或让某个方法返回 error。这些改动不升主版本，却足以让编译失败或运行 panic。
典型现象：
-
undefined: xxx.SomeFunc（函数被移除或重命名） -
cannot use xxx (type Y) as type Z in argument（类型签名变更） -
invalid operation: cannot assign to xxx.ID（结构体字段变为 unexported 或类型不匹配）
验证方式：执行 go list -m -versions github.com/xxx/yyy 查看可选版本，再用 go doc github.com/xxx/yyy@v1.3.0 对比旧版文档，重点扫一眼导出符号列表变化。
go mod tidy 自动引入间接依赖，可能暴露隐藏冲突
go mod tidy 不只是整理 require，它会递归解析所有间接依赖，并把它们的版本写进 go.mod。如果两个直接依赖分别要求 github.com/a/b v1.1.0 和 v1.2.0，而 v1.2.0 里又悄悄依赖了 github.com/x/y v0.5.0，但你的项目某处代码又硬编码调用了 github.com/x/y v0.4.0 的私有函数——go mod tidy 会强制拉 v0.5.0，结果编译报错。
立即学习“go语言免费学习笔记（深入）”；
应对建议：
- 执行
go list -m all | grep x/y确认实际加载的是哪个版本 - 若需锁定旧版，用
replace github.com/x/y => github.com/x/y v0.4.0+ 再跑一次go mod tidy - 注意：
replace后必须go mod tidy，否则go.sum不更新，CI 构建会失败
v2+ 主版本升级不是“升级”，而是新增模块路径
当依赖从 v1 升到 v2，Go 要求模块路径必须带 /v2 后缀。如果你只改了 go.mod 里的 require 行为 github.com/user/lib v2.0.0，但代码里仍写 import "github.com/user/lib"，编译器根本找不到包 —— 它只会加载 v0 或 v1 版本。
正确做法：
- 修改所有 import 语句为
import "github.com/user/lib/v2" - 确认
go.mod中require行也含/v2（如github.com/user/lib/v2 v2.0.0） - 不要把
v2代码放在pkg/v2/这类子目录下 ——go mod init会生成错误模块路径，导致 import 路径对不上
go version 字段不影响依赖选择，但影响语言特性可用性
go.mod 开头的 go 1.21 只控制编译器是否允许使用泛型、try 语句等语言特性，和模块版本无关。MVS（最小版本选择）算法完全忽略这一行，只看 require 声明的约束。
容易混淆的点：
- 即使
go.mod写着go 1.18，你也能go get github.com/xxx@v1.25.0—— 只要该版本本身兼容 Go 1.18 - 但如果新依赖用了 Go 1.22 才支持的
for range变量自动拷贝行为，而你的go字段仍是1.21，编译器不会报错，但运行时逻辑可能出错（比如 goroutine 闭包捕获旧值） - 升级 Go 版本前，先检查
go list -m -u all，再确认关键依赖是否已适配新语言特性
真正难处理的从来不是版本号本身，而是那些没写进 CHANGELOG 的行为变更 —— 比如标准库某个函数在 Go 1.24 里开始校验输入长度，而老代码传了 nil slice 就 panic。这种问题只能靠测试覆盖和日志观察来兜底。
