go get -u 升级单个依赖未生效，因默认只升直接依赖的 minor/patch 版、不改显式锁定版本、不更新间接依赖及 go.sum，且受 GOPROXY 缓存和 replace 干扰。
go get -u 升级单个依赖时为什么没生效
常见现象是执行 go get -u github.com/sirupsen/logrus 后，go.mod 里版本没变，或者仍用旧版。根本原因是 go get -u 默认只升级直接依赖（且仅到最新 minor/patch 版），不处理间接依赖，也不强制刷新 go.sum。
更关键的是：Go 1.16+ 默认启用 GOPROXY，如果代理缓存了旧版本或跳过校验，本地可能拉不到新版。另外，若模块在 go.mod 中已显式写死版本（如 github.com/sirupsen/logrus v1.8.1），go get -u 不会覆盖它。
- 先确认当前版本：
go list -m github.com/sirupsen/logrus - 强制升级到指定版本：
go get github.com/sirupsen/logrus@v1.9.3（直接写明版本） - 升级后运行
go mod tidy，清理未引用的依赖并更新go.sum - 检查是否被 replace 干扰：
go list -m -f '{{.Replace}}' github.com/sirupsen/logrus
升级间接依赖（transitive dependency）的正确姿势
间接依赖不会被 go get 直接修改，必须通过升级其上游直接依赖，或手动触发解析。例如你想升级 golang.org/x/net（被 grpc-go 引入），但项目里没直接 import 它——这时不能对它单独 go get。
真正有效的方式是让 Go 模块解析器重新计算整个依赖图：
立即学习“go语言免费学习笔记（深入）”；
- 用
go get golang.org/x/net@latest+go mod tidy：虽然它是间接依赖，但 Go 会尝试将其提升为直接依赖并更新版本 - 删掉
go.sum再跑go mod tidy（慎用，仅调试时）：强制重拉所有依赖校验和 - 检查谁引入了旧版：
go mod graph | grep 'golang.org/x/net@v0.0.0-2021'，然后升级那个“上游模块”
注意：某些间接依赖版本受 go.mod 中 require 的最小版本约束，即使上游模块已升级，只要满足约束就不会动它。
go mod upgrade 命令不存在？替代方案与工具链选择
Go 官方没有 go mod upgrade 这个子命令。社区常用 go get -u 或 go get -u=patch，但它们行为有限制：
-
go get -u=patch：只升 patch 版（如 v1.2.3 → v1.2.4），不碰 minor/major -
go get -u=minor：升到最新 minor（v1.2.x → v1.3.x），但跳过 major 变更 - 想升 major 版（如 v1 → v2），必须显式写
@v2.0.0，且模块路径要带/v2后缀
如果需要批量升级、按安全漏洞筛选或可视化依赖树，推荐用第三方工具：
-
go list -m all | grep -i "CVE-2023"：粗筛含漏洞关键词的模块 -
github.com/rogpeppe/gohack：临时编辑依赖源码调试，再回写版本 -
github.com/icholy/godown：降级用，反向验证兼容性
升级后测试失败？重点检查这三类兼容性断裂点
Go 模块升级最隐蔽的问题不是编译报错，而是运行时行为变化。尤其要注意：
-
error类型变更：比如github.com/pkg/errorsv0.9.1 → v0.10.0 移除了errors.Cause()，改用errors.Unwrap() - HTTP 客户端默认行为：某些 SDK（如
aws-sdk-go-v2）在 v1.15+ 后默认启用 HTTP/2，可能触发服务端不兼容 - Context 超时传播：
golang.org/x/net/context已废弃，若代码还 import 它，升级后会冲突；应统一用context标准库
建议升级前先跑 go test ./...，再重点看集成测试和日志输出——很多问题只在真实调用链中暴露，静态检查发现不了。
