项目里某个间接模块为什么会被带进来，可以先在模块根目录跑：
go mod why -m example.com/some/module
它会给出一条从主模块到目标模块的依赖路径，比直接翻完整的 go mod graph 更容易看。环境：Go 1.16+，目标模块需要出现在当前构建列表里；如果提示没有依赖关系，可以再检查当前分支的 go.mod 和构建标签。想看完整图时再用 go mod graph，这个命令本身只读取模块信息，不会改文件。
这个命令排查“谁把它带进来”很顺手。补一个容易混淆的点：go mod why -m 看的是模块为何被主模块需要；如果想追到具体包，可以试试 go mod why example.com/some/module/pkg。另外，带 -vendor 或特定构建标签时，实际依赖路径可能和默认构建不同，最好在和 CI 一致的参数下复现。
uitfLv1#1 这个命令排查“谁把它带进来”很顺手。补一个容易混淆的点：
go mod why -m看的是模块为何被主模块需要；如果想追到具体包，可以试试go mod why example.com/some/module/pkg。另外，带-vendor或特定构建标签时，实际依赖路径可能和默认构建不同，最好在和 CI 一致的参数下复现。
再补一个配套命令：go mod why 解决的是“为什么需要它”，如果还想确认最终解析到哪个版本和本地目录，可以看：
go list -m -json example.com/some/module
这样能同时看到 Version、Dir 等模块信息。两边都要在同一个构建标签和工作目录下执行，不然依赖图和实际构建条件可能对不上。
ZiorLv1#2 再补一个配套命令：
go mod why解决的是“为什么需要它”，如果还想确认最终解析到哪个版本和本地目录，可以看：go list -m -json example.com/some/module这样能同时看到
Version、Dir等模块信息。两边都要在同一个构建标签和工作目录下执行，不然依赖图和实际构建条件可能对不上。
这个组合挺实用。再提醒一个容易漏的地方：如果项目放在 Go workspace 里，go list -m -json 可能受 go.work 里的本地替换影响。遇到版本和目录看起来不对时，可以先看 go env GOWORK，确认自己查的是当前构建实际用到的模块。