go mod tidy只补全被import的包并删除既未被import也未被任何非-indirect模块依赖的冗余模块，不清理//indirect间接依赖；其按最小版本选择机制自动升级间接依赖版本，需手动go get固定。
go mod tidy 不会“清理间接依赖”，它只移除真正冗余的模块；你看到的 // indirect 条目绝大多数不该删，也删不掉——强行删了下次 tidy 就会加回来。
go mod tidy 到底删什么、不删什么
它只做两件事：补全所有被 import 的包（包括测试、生成代码、条件编译启用的文件），再删掉 go.mod 中既没被任何 .go 文件 import、也没被剩下那些非-indirect 模块依赖的条目。
- 删：你手动写了
require github.com/foo/bar v1.0.0，但整个项目没有任何地方import "github.com/foo/bar"，且也没其他已保留的依赖需要它 → 这行会被删 - 不删：
golang.org/x/net被github.com/gin-gonic/gin用到了，你没直接 import 它 → 它会留在go.mod里并标// indirect，tidy 绝对不会动它 - 不删：你删了
import "github.com/sirupsen/logrus"，但logrus内部仍依赖golang.org/x/sys→ 后者依然保留，哪怕你代码里一个字都没提它
为什么 // indirect 包版本突然变了
这不是 tidy “搞错了”，而是最小版本选择（MVS）在起作用：当某个直接依赖升级（比如 cloud.google.com/go 从 v0.110.0 升到 v0.112.0），它可能换了个新版本的 google.golang.org/api，go 就会把旧的 // indirect 行换成新的，并更新校验和。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go mod tidy -v会输出类似downgrading google.golang.org/api v0.144.0 => v0.145.0的日志，这就是 MVS 在做决策 - 想锁死？不能靠删或 ignore，得先
go get google.golang.org/api@v0.144.0，让这行变成非-indirect 的require，再跑 tidy - 别信
go mod edit -droprequire对// indirect无效，执行后既不报错也不生效
怎么确认某个间接包是不是真冗余
别猜，用命令验证。重点看它是否被当前构建环境实际拉入依赖图：
- 查引用链：
go mod why -m golang.org/x/sys—— 如果输出main或具体包名，说明它被主模块或某依赖显式需要 - 看是否只在测试里用：
go mod graph | grep 'golang.org/x/sys' | grep test，再配合go test ./...看是否失败 - 模拟删除：
git stash save "temp remove import"→ 临时删掉疑似引入它的import行 →go mod tidy→ 如果那行// indirect消失了，才说明它确实靠那一行带进来
容易被忽略的陷阱：条件编译和运行时加载
tidy 默认只分析当前 GOOS/GOARCH 和启用的构建标签下能被编译的代码。这意味着：
- 带
//go:build linux的文件，若你在 macOS 上跑 tidy，里面import的包会被忽略 → 可能误删 -
import _ "embed"或//go:embed引用的包，Go 1.21+ 需加-compat=1.21才识别，否则 tidy 当作不存在 - 用
plugin.Open()或reflect.ImportPath()动态加载的包，tidy 完全看不到 → 删了就 runtime panic
复杂项目里，间接依赖不是“要不要删”的问题，而是“谁在用、为什么用、改了会不会崩”的问题。每次 tidy 后，go list -m all 和 go mod graph 比对前后差异，比盯着 go.mod 里多出来的 // indirect 行有用得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
