go get module@version 是唯一可靠方式，它只升级目标包、不递归影响其他依赖，自动更新 go.mod 和 go.sum；手动改 go.mod 易被 mvs 规则覆盖，go get -u 会意外升级间接依赖，无法精准控制。
go get module@version 是唯一可靠方式
想只动一个间接依赖，又不扰动其他包，go get module@version 是目前 Go 工具链里最可控的操作。它不会递归升级子树，也不会因为某个间接依赖被其他包拉高而被动“带飞”。执行后，go.mod 中对应 require 行会被覆盖，go.sum 自动更新校验和——前提是该版本能被所有现有约束满足。
常见错误是以为 go get -u 可以“精准控制”，其实它默认会升级目标模块及其全部间接依赖中满足语义化约束的最新 minor/patch 版本，根本做不到“只升一个间接依赖”。
- 必须显式带
@，比如go get golang.org/x/text@v0.15.0；不带会走@latest，可能跳 major - 如果该间接依赖当前没出现在
go.mod的require列表里（即只有// indirect），go get仍会把它提为 direct，并写入版本号 - 若提示
version "v0.15.0" does not exist，先运行go list -m -versions golang.org/x/text确认真实 tag
为什么不能手动改 go.mod 再 tidy
手动编辑 go.mod 中某行 require golang.org/x/net v0.14.0 → v0.15.0，再跑 go mod tidy，看似直接，实则危险。Go 的最小版本选择（MVS）规则会在 tidy 过程中重新计算整个依赖图——只要其他依赖（比如 google.golang.org/grpc）声明需要 golang.org/x/net v0.16.0+，你的手动修改就会被悄悄覆盖回更高版本。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
这不是 bug，而是设计：Go 不把 go.mod 当作硬锁定文件，而是当作“首选提示”。真正起效的是 go get 触发的完整解析 + 校验流程。
- 手动改完不运行
go mod tidy，本地可能构建成功，但 CI 会因go.sum缺失条目失败 - 手动改完运行
go mod tidy，输出里出现upgrading golang.org/x/net就说明 MVS 已干预，你没控制住 - 想绕过 MVS 干预？只能确保该模块未被任何其他依赖间接引入，或用
replace强制锁定（但 replace 不进go.sum，CI 需额外处理）
如何确认这个间接依赖真被你升了
别只看 go.mod，那只是起点。最终参与构建的是 go list -m all 解析出的实际版本，它反映 MVS 计算后的结果。
- 运行
go list -m all | grep 'golang.org/x/text'，输出类似golang.org/x/text v0.15.0才算生效 - 如果输出仍是
v0.14.0，说明有其他依赖在拉低版本约束，用go mod graph | grep 'text'查谁在引用它 -
go mod why golang.org/x/text能显示路径上第一个引用它的包，帮你定位约束源头 - 升级后立刻跑
go test ./...，尤其注意 HTTP、time、encoding 相关行为变更（这些包的小版本升级常带隐性 break）
升级失败时优先检查 GOPROXY 和 GOPRIVATE
很多“版本没变”问题，根源不在命令，而在代理配置。Go 在解析 @commit 或 @branch 时，若 GOPROXY 拦截失败或 GOPRIVATE 没配私有域名，会 fallback 到 git clone，而某些企业 Git 服务器不支持裸 commit 解析，导致静默回退到旧版。
- 确认
go env GOPROXY输出包含可用源（如https://goproxy.cn,direct） - 私有模块必须加进
GOPRIVATE，否则go get github.com/your-org/internal@abc123会失败 - 临时排除缓存干扰：可加
-x参数看详细 fetch 日志，或go clean -modcache后重试
replace。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
