间接依赖会悄悄升级是因为Go默认采用最小版本选择（MVS）策略，按语义化版本规则选取满足所有依赖约束的最新兼容版本；可用go get -u=patch控制仅patch级升级，或手动require并删除//indirect锁定特定版本。
为什么间接依赖会悄悄升级
间接依赖（即你没直接 import，但某直接依赖用到的包）在执行 go get -u 或 go mod tidy 时可能被升级，根本原因是 Go 默认采用最小版本选择（MVS）策略——它会按语义化版本规则，选一个满足所有依赖约束的“最新兼容版本”。比如 A 依赖 github.com/foo/bar v1.2.0，B 依赖 v1.5.0，Go 就会选 v1.5.0，哪怕你从没写过那行 require。
用 go get -u=patch 控制升级粒度
这是最轻量、最常用的方式：只允许 patch 级别升级（如 v1.2.3 → v1.2.4），不碰 minor/major（v1.2.x → v1.3.0 或 v1.x → v2.x）。适合日常维护，避免意外行为变更。
-
go get -u=patch升级所有直接依赖的 patch 版本，同时保持其间接依赖不越界 -
go get -u=patch github.com/sirupsen/logrus只针对该包及其传递依赖做 patch 升级 - 注意：
-u=patch不影响已显式写死在go.mod中的间接依赖版本
手动 require + 删除 // indirect 锁定特定间接依赖
当你发现某个间接依赖的行为变化影响了你的代码（比如 golang.org/x/net 的 DNS 解析逻辑变更），又无法修改它的直接引用者时，就得把它“扶正”：从间接变成显式依赖。
- 运行
go get github.com/problematic/pkg@v1.2.3，它会在go.mod中添加一行带// indirect的require - 手动删掉该行末尾的
// indirect注释，使它成为直接依赖项 - 再执行
go mod tidy，Go 会优先采纳这个版本，并在 MVS 计算中赋予更高权重 - 后续若其他依赖要求更高版本，仍可能触发升级——所以要配合
go list -m all | grep problematic定期检查实际选用版本
CI 中防止间接依赖漂移的硬性检查
本地开发时容易忽略间接依赖变动，但 CI 是最后一道防线。光靠 go.sum 不够，因为它是校验快照，不是变更记录。
- 在 CI 脚本里加一句：
git status --porcelain go.mod go.sum，非空就失败 - 更进一步：运行
go list -m all | grep -v 'your-module-name'，对比前后输出，识别哪些间接依赖被改了 - 禁止在 CI 中执行
go mod download后提交新go.sum——这会让本地go mod verify失败，因为校验和来源不一致
真正难的不是“怎么锁”，而是判断该不该锁：有些间接依赖升级是安全的（如文档修复、测试工具），有些却会改变 JSON 序列化默认行为或 HTTP 超时逻辑。得结合 go mod graph 和 CHANGELOG 做针对性决策，而不是一刀切冻结全部。
