Go 1.16+ 中 go get -u ./... 默认只升级到兼容的最新补丁版本（patch），不升次版本（minor）；若需升 minor，须显式指定 go get -u=minor ./...。
go get -u ./... 为什么不再升级次版本
Go 1.16 起，go get -u 默认只升级到**兼容的最新补丁版本（patch）**，不再自动升次版本（minor），这是模块语义化版本策略的强制行为。你执行 go get -u ./... 后发现 github.com/sirupsen/logrus 还卡在 v1.8.1，不是命令没跑，是它压根不认为 v1.9.0 是“安全可升”的目标。
- Go 模块升级逻辑基于
go.mod中声明的require版本范围：比如github.com/sirupsen/logrus v1.8.1表示“接受 v1.8.x，但不自动跨 v1.9.x” -
-u只会找满足当前主版本约束的**最高 patch 版本**（如从 v1.8.1 → v1.8.2），除非你显式写成v1.9.0或用-u=patch/-u=minor - 运行
go list -u -m all可看到哪些模块有可升的次版本（带[newest]标记），但不会自动应用
想升 minor 版本，必须加 -u=minor 参数
直接运行 go get -u=minor ./... 才会把所有依赖升到各自主版本下的最新次版本（例如 v1.8.1 → v1.9.0，但不会升到 v2.0.0）。
-
-u=minor仍受go.mod主版本号限制：若 require 写的是v1.8.1，它最多升到v1.x.y最高 minor；若要跨 v2，得手动改go.mod并加+incompatible或启用 v2 module path - 升级过程会自动更新
go.mod和go.sum，但不会自动修复 API 变更导致的编译错误 - 建议先
git status确认工作区干净，再执行，避免升级后无法回退
升级后编译失败？大概率是 API 不兼容
次版本升级不保证 100% 向后兼容，尤其像 golang.org/x/net、google.golang.org/grpc 这类高频迭代库，v1.19.0 可能已删掉某个函数或改了参数顺序。
- 常见报错如：
undefined: http2.ConfigureServer、cannot use x (type string) as type []byte in argument to y - 先用
go mod graph | grep 库名查清谁间接拉入了这个依赖，再看它的CHANGELOG.md或 release note - 临时解法：用
replace锁定旧版，例如在go.mod加一行replace github.com/gorilla/mux => github.com/gorilla/mux v1.8.0 - 不要依赖
go get -u=minor一键平滑升级 —— 它只管下载，不管适配
更可控的升级方式：逐个指定 + 验证
对关键项目，比 ./... 全量升级更稳妥的是按模块名精确控制，配合 go list 辅助判断。
立即学习“go语言免费学习笔记（深入）”；
- 查某依赖当前可用的最新 minor：
go list -m -versions github.com/spf13/cobra - 升指定模块到最新 minor：
go get github.com/spf13/cobra@latest（注意：@latest 会跨主版本，慎用）或go get github.com/spf13/cobra@v1.8.0 - 升完立刻
go build+go test ./...，别等 CI 报错才反应过来 - CI 中建议固定 Go 版本（如
1.21.10）和依赖版本，避免本地能过、CI 失败
真正麻烦的从来不是命令怎么敲，而是升级后 runtime panic 或测试里浮点误差变大这种不报错但逻辑错的问题 —— 它们不会出现在 go build 输出里，得靠你心里有数，盯着日志和 case 覆盖率看。
