最稳的更新方式是go get github.com/xxx/yyy@v1.2.3，它只更新目标包、不递归升级间接依赖；必须显式带@指定版本，否则可能跨主版本导致编译失败；执行后自动更新go.mod和go.sum，但需再运行go mod tidy同步未引用的新增依赖。
最稳的更新方式是 go get github.com/xxx/yyy@v1.2.3，它只动目标包、不递归升级间接依赖；不带 @ 版本号直接 go get 或滥用 go get -u，极大概率导致编译失败或运行时 panic。
用 go get module@version 精确升级单个依赖
这是日常维护中副作用最小的操作。它只修改目标模块的 go.mod 行，不碰其他依赖，也不会触发间接依赖的连锁升级。
-
@后必须是明确版本标识：有效 tag（如v1.9.3）、commit hash（如@3f5e566）或分支名（如@main），@latest不可靠——它取的是最新 semver tag，不是master分支最新 commit - 执行后
go.mod和go.sum会自动更新，但不会下载未被代码import的包；如果只是加了依赖还没实际引用，得再跑一次go mod tidy - 若提示
require github.com/xxx: version "v1.9.3" does not exist，说明该 tag 在仓库中不存在，需先查go list -m -versions github.com/xxx确认可用版本
为什么 go get -u 经常出问题
go get -u 看似“一键升级”，实际行为复杂且隐性：它会递归升级所有间接依赖到各自最新 minor/patch 版本，而很多库并不严格遵守语义化版本。
-
go get -u ./只作用于当前模块下所有子目录包的直接依赖，仍不升级// indirect标记的间接依赖，除非它们被某个 direct 依赖的新版本重新引入 - v0.x 包无兼容性保证，
-u可能悄悄引入破坏性变更；某些-u锁定的 commit 甚至没打 tag，后续go mod download直接失败 -
-u会忽略go.mod中的replace和exclude规则，强行拉取 upstream，可能导致本地 fork 被覆盖回退
主版本升级（如 v1 → v2）必须手动改 import 路径
Go 模块要求 v2+ 必须体现在 import 路径中，例如从 import "github.com/xxx/lib" 改为 import "github.com/xxx/lib/v2"。漏掉这步，编译必报错。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 先运行
go list -m -versions github.com/xxx/lib确认 v2+ 是否存在；再执行go get github.com/xxx/lib/v2@v2.0.0，它会在go.mod中写入新路径 - 全局搜索替换所有
import "github.com/xxx/lib"→import "github.com/xxx/lib/v2"，注意检查测试文件和 internal 包 - 同一项目不能同时 import v1 和 v2 的同一模块（路径不同也算不同模块），否则
go build报duplicate symbol类错误
go mod tidy 不是升级命令，而是校验器
它不主动升版本，只按当前代码里的 import 语句比对 go.mod：缺了就加，多了就删，go.sum 也一并刷新。很多人误以为运行它就等于“更新完成”，其实只是清理现场。
- 刚克隆项目、删了
import、或想清理// indirect依赖时才该用它；它不会把logrus v1.8.1升到v1.9.0，除非你先用go get触发 - CI 中必须加
-v参数：go mod tidy -v，否则看不到它实际增删了哪些模块，难以定位意外变更 - 本地有未提交的
go.mod修改（比如手动删了一行），tidy会把它还原——它只信代码里的import，不信你手写的require
真正容易被忽略的是验证环节：Go 不会在 go get 后自动检查你的代码是否还能编译、是否调用了已移除的函数。每次更新后必须跑 go test ./ 和 go vet ./，尤其要关注间接依赖的行为变化——比如 golang.org/x/net 升级后 http2 默认超时逻辑可能不同。
