手动改go.mod中require版本号无效，因Go不响应文件变更，必须用go get触发下载与校验；忽略go.sum会丧失防篡改能力，导致构建不一致；indirect依赖需用go mod graph定位并谨慎exclude或升级。
Go 依赖版本管理不是“越统一越好”，而是“越可复现、越可追溯、越少隐性变更越好”。盲目追求所有模块版本对齐，反而会放大冲突风险、掩盖真实依赖路径。
go.mod 中手动改版本号为什么无效
直接编辑 go.mod 文件里某行 require github.com/some/lib v1.2.0 并不能让 Go 拉取或校验这个版本。Go 工具链不监听文件变更，只响应命令驱动的解析流程。
- 必须用
go get github.com/some/lib@v1.2.0触发下载、写入go.mod和更新go.sum - 若该版本不存在或被 proxy 缓存污染，
go get会静默 fallback 到其他兼容版本（比如@latest） -
go mod tidy不会“修正”你手写的错误版本，它只清理未引用项、补全缺失依赖，不会回滚或覆盖已存在的 require 行
go.sum 被忽略或未提交是高危操作
go.sum 不是锁文件，是每个模块内容的 SHA256 校验快照。跳过它等于放弃防篡改能力。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- CI 构建时若没拉到最新
go.sum，可能从 proxy 下载到被污染/替换过的同版本 zip 包，导致运行时 panic -
go build -mod=readonly报错missing go.sum entry，说明某require条目无对应校验和——这不是“漏了”，是校验机制在拦截非法状态 - 修复方式只有两种：
go mod download补全校验和，或git add go.sum提交后重新构建 - 切勿把
go.sum加进.gitignore；也不要用go mod vendor替代它——vendor 是缓存，go.sum是信任锚点
如何安全处理间接依赖（indirect）升级
go list -m all 显示大量 // indirect 条目是正常现象，但其中某个子依赖悄悄升到 v1.20.0，就可能破坏日志格式、HTTP header 行为或 context 取消逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 先定位来源：
go mod graph | grep 'bad/pkg'查谁引入了它 - 若上游已发布含 bug 的版本，用
exclude github.com/bad/pkg v1.3.0在go.mod中阻止该版本被选中 - 慎用
replace：它绕过go.sum校验，且影响整个模块树对该路径的所有引用；仅限本地调试 fork 分支，上线前必须删掉 - 定期执行
go list -deps -f '{{.Path}} {{.Version}}' ./...对比前后差异，比盯着go.mod更早发现隐性变更
真正难控的从来不是版本号本身，而是某个 // indirect 模块在无人关注时替换了接口默认行为——比如 http.Client 默认超时从 0 变成 30s，或 logrus 新版本自动注入 trace 字段。这类变化不会报编译错，却会在压测或灰度时突然暴露。
