Go Module 选用版本由MVS算法动态决定，非go.mod中require声明的固定版本；MVS取所有依赖中最高版本下界，确保兼容性而非最小版本号。
Go Module 为什么选了这个版本，而不是我 go.mod 里写的那个？
Go 不会按你 go.mod 中写的 require example.com/lib v1.2.0 就一定用 v1.2.0——它只把这行当作“最低需求”，真正选哪个版本，由 MVS（Minimal Version Selection，最小版本选择）算法在构建时动态决定。
常见错误现象：go build 成功，但运行时报 undefined: someFunc；或者本地 go run 没问题，CI 上却失败。本质是：你本地 go.sum 锁定了某个版本，而 CI 拉的是另一套依赖图，MVS 算出来不同。
- MVS 从主模块（你的项目）出发，递归收集所有
require声明的**最高版本下界**，不是“我要用 v1.2.0”，而是“我至少需要 v1.2.0 才能编译” - 如果另一个依赖
requires example.com/lib v1.5.0，那 MVS 就会升到 v1.5.0，哪怕你只写了 v1.2.0 -
go get -u会尝试升级到最新兼容版，但go get -u=patch只升补丁版，这是控制 MVS 范围最直接的手段
go mod graph 输出看不懂？怎么快速定位谁拉高了某个依赖的版本？
go mod graph 输出是扁平的边列表，人眼难追踪。真正有用的是结合 grep 和反向过滤：
go mod graph | grep 'example.com/lib@' | grep -v 'your-module-name'
这条命令能筛出“谁间接依赖了 example.com/lib”，从而发现隐藏的升级源。常见场景：你没动 go.mod，但 go list -m all | grep lib 显示版本跳到了 v1.8.0——大概率是某个二级依赖悄悄升级了它的 require。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 注意
go mod graph不包含indirect标记的行，要查间接依赖得加go list -m -u all - 如果某依赖被多个路径拉起，MVS 总是取其中**最高版本下界**，不会降级妥协
- 想临时压低版本？可以显式
go get example.com/lib@v1.2.0，Go 会重写go.mod并加入// indirect注释，但这只是覆盖，不是屏蔽
go.sum 文件里一堆校验和，删掉重生成会出问题吗？
不会破坏构建，但可能引入不一致。Go 在首次 go build 或 go mod download 时，自动把每个模块的 zip 包哈希写进 go.sum；后续构建会校验，防止篡改或中间人攻击。
- 删掉
go.sum后运行go mod tidy，Go 会重新下载所有依赖并生成新校验和——前提是网络可达、模块代理可用 - 风险点：如果某个模块在不同时间发布了同 tag 的不同内容（极少见但可能），新生成的
go.sum会记录新版哈希，导致团队间行为差异 - CI 中建议保留
go.sum并提交，不要.gitignore它；否则每次构建都可能因代理缓存或网络抖动拿到不同 zip
为什么 go mod vendor 后，vendor/ 下的版本还是跟 go list -m all 不一致？
go mod vendor 不是简单拷贝 go.mod 列出的版本，它执行一次完整的 MVS 计算，再把结果集里的**所有模块**（包括 indirect 的）拉进来。所以 vendor 目录反映的是“当前构建实际用到的最小闭包”，而非你手动 require 的子集。
- 如果你希望 vendor 更“干净”，可以用
go mod vendor -o ./vendor-clean配合go mod edit -dropreplace清理 replace 规则，避免意外带入本地路径模块 - vendor 后运行
go build -mod=vendor才真正隔离外部模块；只go build仍会读go.mod并走网络 - 注意：vendor 不解决跨平台问题——
vendor/里的代码仍是源码，不是预编译产物；Windows 下的buildmode=c-archive仍需重新编译
MVS 的“最小”二字容易误解：它求的不是版本号最小，而是满足全部约束的**最保守升级解**。真正难调试的，往往是某个 indirect 依赖悄悄抬高了下界，而你只盯着自己写的 require 行看。
