直接修改 go.mod 的 require 行无效，必须用 go get module@version 修改并触发同步；go.sum 与 go.mod 共同锁定版本，缺一不可；主版本 ≥ v2 需带路径后缀；降级需清理 go.sum 对应条目。
直接改 go.mod 文件里的 require 行不能生效，必须配合命令触发同步；真正锁定版本靠的是 go.sum 和 go.mod 共同作用，缺一不可。
用 go get module@version 精确修改单个依赖
这是最推荐、副作用最小的方式。它只动目标模块，不递归升级间接依赖，且自动更新 go.mod 和 go.sum。
-
@后必须是有效语义化版本（如v1.9.3）、commit hash（如@a1b2c3d）或分支名（如@main），不能写模糊词如@latest（它可能跨主版本） - 主版本 ≥ v2 必须带路径后缀，例如升级到
cobra/v2：运行go get github.com/spf13/cobra/v2@v2.0.0，而不是go get github.com/spf13/cobra@v2.0.0 - 执行后务必检查
go.mod是否写入了你预期的版本号，并确认go.sum新增/修改了对应条目；若没变，可能是GO111MODULE=off或GOPROXY缓存干扰
手动编辑 go.mod 后必须跑 go mod tidy
单纯在 go.mod 里把 github.com/sirupsen/logrus v1.8.1 改成 v1.9.3 不会下载代码、也不会更新校验和——Go 工具链不会主动响应这种“静态修改”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go mod tidy的作用是扫描所有.go文件中的import，然后按go.mod声明的约束补全或删除依赖，同时刷新go.sum - 如果改完
go.mod就直接go build，很可能报错no required module provides package xxx，因为缺失的模块还没被拉取 - CI 中建议加
-v参数：运行go mod tidy -v，可看到实际增删了哪些模块，便于快速发现意外变更
go mod tidy 不会主动升级，但可能悄悄“提级”
它本身不升级版本，但会服从最小版本选择（MVS）规则：如果某个间接依赖已通过其他路径引入更高版本，tidy 会把 go.mod 里你写的低版本“提级”以满足一致性。
立即学习“go语言免费学习笔记（深入）”；
- 例如你写了
require github.com/gorilla/mux v1.8.0，但另一个依赖要求v1.9.4，go mod tidy会自动改成v1.9.4 - 这容易被当成“意外升级”，其实是 Go 模块系统的正常行为；想避免，就得显式声明所有关键依赖版本，不依赖传递
- 升级前先查当前解析结果：
go list -m all | grep mux，比只看go.mod更真实
回滚依赖版本要连 go.sum 一起清理
降级不是“改回去就完事”。旧版本的校验和可能还留在 go.sum 里，导致 go build 报 checksum mismatch。
- 正确流程：运行
go get github.com/sirupsen/logrus@v1.8.1→ 检查go.mod和go.sum是否更新 → 若仍报校验失败，手动删掉go.sum中该模块所有旧条目，再跑一次go mod tidy - 私有模块或非官方镜像源下，
go.sum是唯一防篡改依据，丢失它等于放弃依赖可信链 - 团队协作中，
go.sum必须提交进 Git；CI 流水线应加git status go.sum检查，防止意外修改未被发现
