Go项目依赖升级需分场景策略化操作：go get -u默认仅升当前主版本内最新minor/patch，跨主版本须手动修改import路径并执行go get @vX.x.x；protobuf等工具链需同步升级generator与runtime；go mod tidy不解决冲突，须结合go mod graph等命令排查。
Go 项目升级依赖不是“一键更新”就能完事，关键在于区分 go get -u 的默认行为（只升 minor/patch）、主版本共存的路径约束、以及 protobuf 类工具链的生成兼容性。盲目用 @latest 或跳过测试，90% 的线上故障都出在这几步。
go get -u 默认不升级主版本，这是设计，不是 bug
执行 go get -u ./ 或 go get -u github.com/sirupsen/logrus 时，Go 模块解析器只会将依赖升到当前主版本下的最新 minor/patch 版本（如从 v1.8.1 升到 v1.9.3），绝不会跨到 v2.0.0。这是因为 Go 要求 v2+ 必须改导入路径（如 github.com/sirupsen/logrus/v2），而 go get -u 不会自动改代码里的 import 语句。
- 想升 v2？必须手动改两处：go.mod 中的
require行加/v2后缀，且所有import语句同步改成带/v2的路径 - 升完立刻跑
go test ./—— v2 的类型、函数签名、返回值通常和 v1 不兼容，编译失败是常态 - 如果只是想看哪些包有新主版本可选，先跑
go list -m -u all，输出里带[new major version]的才需要人工介入
protobuf 生成代码升级必须同步 toolchain 和 runtime
GoGo Protobuf（或 google.golang.org/protobuf）升级时，最常踩的坑是：只更新了 go.mod 里的库版本，却没更新 protoc-gen-go 或 protoc-gen-gogo 插件，导致新生成的 .pb.go 文件和运行时库不匹配，编译报错或运行时 panic。
- 检查当前生成器版本：
protoc-gen-go --version和go list -m google.golang.org/protobuf必须对齐（比如都是 v1.32.x） - 升级前先删掉旧的
.pb.go文件，再重新protoc生成，避免残留字段或方法冲突 - 若项目同时用 gogo 和官方 protobuf，务必在
go.mod中显式replace所有相关模块到同一语义版本，否则go mod graph会暴露出多个不兼容的proto运行时实例
go mod tidy 不是万能清洁剂，它可能掩盖冲突
go mod tidy 会补全缺失依赖、删掉未引用的 require，但它不会解决版本冲突。当两个间接依赖分别要求 github.com/gorilla/mux v1.8.0 和 v1.9.1 时，tidy 会选一个满足两者的最小版本（通常是 v1.9.1），但如果你的代码强依赖 v1.8.0 的某个已移除行为，它照样编译通过、运行时报错。
立即学习“go语言免费学习笔记（深入）”；
- 查冲突根源用：
go mod graph | grep gorilla/mux看谁在拉哪个版本 - 强制锁定版本：在
go.mod中加一行github.com/gorilla/mux v1.8.0，tidy就会按这个走 - 排除已知问题版本：
exclude github.com/gorilla/mux v1.9.0（比如该版有严重内存泄漏） - 本地调试时，
go clean -modcache再重试，避免缓存污染导致版本判断失真
真正容易被忽略的，是生成代码与 runtime 库的隐式耦合——比如 protobuf 字段 tag 变更、jsonpb 与 protojson 行为差异、甚至 go.sum 里某条校验和因 vendor 工具链不同而失效。这些都不会在 go build 阶段报错，而是在特定请求路径下才触发。上线前至少跑一次真实流量回放或集成测试。
