go get -u 不适合指定升级，因为它会递归升级目标包的所有间接依赖（只要满足语义化版本约束），易引发兼容问题；而 go get package@version 仅精准升级目标包及其直接依赖，副作用最小。
直接用 go get package@version 升级指定包，是最可靠、副作用最小的方式。它只改目标包及其满足约束的直接依赖，不会连带升级其他间接依赖；而 go get -u 表面是“升级”，实际会递归扫整个子树，容易引发意外兼容问题。
为什么 go get -u 不适合“指定升级”
go get -u 的行为和你想的不一致：它默认升级目标包的所有间接依赖，只要这些依赖满足语义化版本约束，就会被拉到最新 patch 或 minor 版本。
- 例如执行
go get -u github.com/spf13/cobra，可能顺手把golang.org/x/net从v0.14.0升到v0.22.0 - 如果某个间接依赖在
go.mod中只写了v1.2.0，但 cobra 要求v1.2.5+，go get -u就会把它升上去——你完全没意识到 - 想只升 cobra？去掉
-u，改用go get github.com/spf13/cobra@v1.8.0
go get package@version 执行后要检查什么
命令跑完不代表成功。常见现象是 go.mod 没变、go list -m all 还是旧版。问题通常出在环境或输入上：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go env GO111MODULE必须是on；若在$GOPATH/src下运行，会退化为 GOPATH 模式，忽略go.mod -
GOPROXY配置错误（比如设成不可达地址或漏掉direct），会导致 fallback 到git clone，私有仓库或带/v2后缀的模块可能解析失败 - 版本号不存在：先用
go list -m -versions github.com/xxx/yyy确认 tag 是否真存在（注意前缀v）；有些仓库打 tag 不规范（如1.2.3而非v1.2.3），go list查不到，但go get @commit仍可用
v2+ 主版本升级要额外处理 import 路径
Go 要求 v2+ 模块路径必须带 /v2 后缀，否则视为不兼容。这不是改 go.mod 就完事的事。
立即学习“go语言免费学习笔记（深入）”；
- 先运行
go get github.com/xxx/yyy/v2@v2.3.0，go.mod里会新增一行github.com/xxx/yyy/v2 v2.3.0 - 然后必须全局替换代码里的
import "github.com/xxx/yyy"→import "github.com/xxx/yyy/v2" - 如果项目里用了 vendor，还要确认
vendor/目录下是否已更新对应路径，否则运行时仍可能加载旧版
v2+ 升级最容易漏的是 import 路径替换，尤其当项目里有多处引用、或通过别名导入时，静态检查工具不一定能全覆盖，得靠 grep 或 IDE 全局搜索确认。
