go get -u 默认升级到主版本号相同的最新次版本或修订版本，不会跨主版本升级，具体行为受 go.mod 中 require 行的版本约束。
go get -u 会更新到哪个版本
go get -u 默认只升级到**主版本号相同**的最新次版本（minor）或修订版本（patch），不会跨主版本升级。比如当前是 v1.2.3，执行后可能升到 v1.5.0 或 v1.2.9，但不会跳到 v2.0.0——除非模块路径本身带 /v2 后缀。
实际行为还受 go.mod 中现有 require 行约束：如果写的是 github.com/some/pkg v1.2.3，go get -u 会尊重该版本前缀，只找 v1.x.x 范围内的最新版；如果写的是 github.com/some/pkg latest（不推荐），则可能拉取不兼容的 v2+，前提是模块声明了对应路径。
- 想强制升级到某具体版本？用
go get github.com/some/pkg@v1.8.0 - 想升级到最新 patch（保持 minor 不变）？用
go get -u=patch github.com/some/pkg - 升级时发现依赖冲突？先看
go list -m all | grep some/pkg确认当前解析出的实际版本
go.mod 中 require 行的版本语义很重要
Go 模块版本不是“越新越好”，require 行写的版本号直接决定 go build 和 go get 的解析逻辑。例如：
require github.com/gorilla/mux v1.8.0表示锁定在 v1.8.0，后续 go get -u 不会动它；而：
立即学习“go语言免费学习笔记（深入）”；
require github.com/gorilla/mux v1.8.1-0.20220101000000-abcdef123456是 pseudo-version（伪版本），通常出现在未打 tag 的提交上，这种写法容易在下次 go mod tidy 时被自动替换为更稳定的 tag 版本，导致行为漂移。
- 生产项目建议显式指定稳定 tag，避免用
latest或 commit hash - 升级前先
go list -u -m github.com/some/pkg查看可用更新，它会显示当前版本和最新可用版本 - 如果模块已发布 v2+，且你确实需要，必须改
require行为github.com/some/pkg/v2 v2.0.0，路径和导入语句也得同步加/v2
go mod tidy 不只是清理，它会隐式升级
go mod tidy 的核心任务是让 go.mod 和代码中的 import 保持一致，但它在补全缺失依赖时，**默认使用模块的 latest stable tag**，而不是你本地 go.sum 里记着的旧版本。
这意味着：即使你没运行 go get，只要新增了一个 import，再跑 go mod tidy，就可能把某个间接依赖从 v0.5.0 升到 v0.7.0，尤其当该模块近期打了新 tag。
- 检查是否发生隐式升级？对比
git diff go.mod运行前后 - 想禁用这种行为？暂时用
go mod tidy -compat=1.17（仅限兼容性控制，不阻止升级）；真正可控的方式是提前go get xxx@v0.5.0锁死 - CI 中建议加
go mod tidy -v && git diff --exit-code go.mod go.sum，确保提交的依赖状态与本地一致
升级后编译通过 ≠ 行为不变
Go 没有严格的语义化版本强制规范，很多包在 minor 版本里也会引入破坏性变更（比如函数签名改、默认行为变、Error 类型换）。常见现象包括：
- 测试通过但 http handler 返回 500：
gorilla/handlers在 v1.5.0 后对空Host头处理更严格 - 日志突然消失：某些 logger 包在新版本里默认关闭了 console 输出
-
json.Marshal结果多出字段：第三方 Struct tag 解析逻辑变更
所以升级后务必验证真实调用路径，不只是跑单元测试。如果项目用了大量外部 client，建议在 go.mod 里用 // indirect 注释标出哪些是传递依赖，并定期用 go list -m -u all 扫描可更新项，挑关键包手动升级+验证。
最易被忽略的一点：vendor 目录存在时，go build 仍以 go.mod 为准，vendor 只是缓存；删 vendor 并不会回退版本，真正回退得改 go.mod 并 go mod tidy。