go mod why 报 unknown pattern 的直接原因是模块路径错误，需使用完整可解析路径（如 github.com/sirupsen/logrus），且项目必须有有效 go.mod；跨模块依赖须已在 go.sum 中存在。
go mod why 报 unknown pattern 怎么办
直接原因是模块路径写错了，go mod why 只接受「已知模块路径」或「包导入路径」，不支持模糊匹配或本地相对路径。
- 必须用完整的、可被 Go 模块解析的路径，比如
github.com/sirupsen/logrus，不能写成logrus或./vendor/logrus - 如果项目没启用 module（即无
go.mod），命令会失败；先确认当前目录下有有效的go.mod - 跨 module 依赖时，目标包必须已在
go.sum中出现过，否则提示unknown pattern—— 可先跑一次go list -deps ./...看它是否真被引入
为什么 go mod why -m 和不加 -m 结果差很多
-m 表示按模块层级分析，不加则按包导入路径分析 —— 这是理解依赖来源的关键分水岭。
- 不加
-m：查某个具体包（如golang.org/x/net/http2）被谁 import，输出的是「直接 import 它的 Go 源文件」 - 加
-m：查整个模块（如golang.org/x/net）为何出现在go.mod中，输出的是「哪个依赖项拉进了这个模块」 - 常见误判场景：你删了某行
import，但go mod why仍显示存在 —— 很可能它是被间接依赖的模块拉进来的，此时必须加-m
依赖链里出现 (root) 或 (main) 是什么意思
这表示该包/模块是项目顶层显式声明的依赖，不是被其他依赖带进来的。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
(root)：出现在go.mod的require块中，是你自己手动go get或编辑添加的 -
(main)：通常指当前模块自身（即module github.com/xxx/yyy那一行定义的模块），在分析自己内部子包依赖时会出现 - 注意：
(root)不代表安全或可控 —— 如果你go get github.com/evil/pkg@v1.0.0，它也会标为(root)，但可能是高危依赖
想看完整依赖路径但输出被截断了怎么办
go mod why 默认只显示一条最短路径，遇到多条路径时不会自动展开，容易漏掉关键中间依赖。
立即学习“go语言免费学习笔记（深入）”；
- 用
go mod graph | grep手动筛：比如go mod graph | grep 'golang.org/x/net' | head -10，能看见所有引入它的模块 - 配合
go list -f '{{.Deps}}' -json ./...可导出全量依赖树（JSON 格式），适合脚本处理 - 真正要定位「谁偷偷升级了某个模块」，别只信
why的单条路径 ——go mod graph+go list -m -u all组合更可靠
依赖分析不是一次 go mod why 就能闭环的事，尤其当 replace、exclude 或多模块 workspace 存在时，路径可能绕过常规解析逻辑。
