go get -u 不会升级到 v2+ 版本，因为 Go 将主版本升级（如 v1→v2）视为全新模块，仅在当前主版本内升级 minor/patch；升 v2 必须显式使用 /v2 路径、更新 go.mod 和所有 import 语句。
go get -u 为什么不会升级到 v2+ 版本
因为 Go 模块的主版本递增（如 v1 → v2）被视作一个**全新模块**，而非原模块的“升级”。go get -u 只会在当前主版本内找最新 minor/patch 版本，它不会跨 v1 和 v2 的边界。
常见错误现象是：执行 go get -u github.com/sirupsen/logrus 后，go.mod 里仍是 v1.10.0，但远程已有 v2.0.0 —— 这不是命令失效，而是设计如此。
- 要升到 v2，必须显式写路径：
go get github.com/sirupsen/logrus/v2@latest - 同时，所有
import语句也得改成import "github.com/sirupsen/logrus/v2"，否则编译失败 - 如果旧代码还混用 v1，Go 允许两者共存，但需确保无符号冲突（比如都定义了同名函数）
module 路径里不加 /v2 就无法使用 v2+ 版本
这不是约定，是 Go 模块系统的硬性规则。v2+ 模块的 go.mod 文件第一行必须声明带 /v2 的路径，例如：module github.com/sirupsen/logrus/v2。
如果你看到某个仓库发布了 v2.0.0 tag，但它的 go.mod 仍是 module github.com/sirupsen/logrus，那这个 v2.0.0 在 Go 模块体系下**根本不可用**——go get 会拒绝解析，报错类似 unknown revision v2.0.0。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 发布 v2+ 时，维护者必须新建
go.mod并更新 import 路径，否则下游无法消费 - 你自己维护的私有模块也要遵守：想发 v2，就得建
/v2子目录或重命名模块路径 -
replace也不能绕过这条规则；用replace github.com/sirupsen/logrus => ./local-logrus时，本地go.mod仍需是/v2路径
@latest 不等于最新 tag，更不等于 master 分支
@latest 是 Go 模块解析器根据语义化版本规则选出的「最高合法 patch 版本」，它会跳过预发布版（如 v2.0.0-beta.1），也不会取未打 tag 的 commit。
典型误操作是：你看到 GitHub 上 master 分支有新功能，就跑 go get github.com/gorilla/mux@latest，结果拉下来的还是 v1.8.0 —— 因为最新 tag 是 v1.8.0，而 v2.0.0 尚未发布或路径不对。
- 查真实最新 tag：运行
go list -m -versions github.com/gorilla/mux - 想试未发布功能，得用 commit hash：
go get github.com/gorilla/mux@5a12b3c -
@master或@main是非语义化引用，CI 中应避免，因内容不稳定且无法复现
go mod tidy 不会主动升级任何版本
go mod tidy 的唯一职责是同步 go.mod 与实际代码中的 import 关系：删掉没被引用的 require，补上缺失的间接依赖。它**完全不关心远程是否有新版**。
很多人执行完 go mod tidy 就以为依赖已更新，结果 go test 失败才发现还在用半年前的 golang.org/x/net —— 因为代码里没新增 import，tidy 就不动它。
- 真正升级必须靠
go get驱动，哪怕只是go get github.com/some/lib@v1.2.0 - 升级后务必再跑一次
go mod tidy，否则可能残留旧间接依赖或漏写go.sum - CI 中若只跑
tidy不跑get，等于没做版本更新
主版本升级最易被忽略的点是：它不只是改个数字，而是触发整条导入链的路径变更、工具链兼容性检查、以及测试覆盖范围的重新评估。别只盯着 go get 命令是否成功，要确认 import、go.mod、go.sum、测试结果全部对齐。
