直接看go mod graph只能拿到扁平有向边，非树形结构；真正还原引用路径需组合go mod why -m（查最短导入链）、go list -m all（确认模块存在性及indirect/replace状态）和人工过滤，因依赖流是构建时动态拼合的结果。
直接看 go mod graph 只能拿到边，不是流；真正要还原“谁在什么路径下引用了谁”，得组合 go mod why -m、go list -m all 和人工过滤逻辑。
用 go mod why -m 追一条最短引用路径
它不展示全图，只返回从主模块出发、能抵达目标模块的**一条最短 import 链**。适合快速确认“这个包到底为什么在这”：
- 必须加
-m参数，否则默认查包路径（go mod why github.com/foo/bar会报unknown import path） - 如果目标模块是
indirect或被replace覆盖，go mod why -m仍能工作，但显示的是原始模块名（比如replace github.com/foo/bar => ./local后，仍要查go mod why -m github.com/foo/bar） - 输出里每行是一个 import 节点，顺序即引用流向：第一行是主模块，最后一行是目标模块，中间全是传递依赖
- 它不保证覆盖所有路径——多个上游引入同一模块时，只返回第一个找到的链；需配合
go mod graph | grep手动补全
用 go mod graph 提取所有原始依赖边
go mod graph 输出的是扁平有向边，格式为 A B@v1.2.3，本质是「A 的源码里 import 了 B」的静态证据。它是构建引用流的原始数据源：
- 不处理
replace和exclude：即使你本地replace github.com/old/pkg => ./fix，输出里仍是github.com/old/pkg@v1.0.0，容易误判真实引用来源 - 包含所有间接依赖，行数可能上千；常用过滤方式：
go mod graph | grep "^$(go list -m) " | cut -d' ' -f2查主模块的直接下游 - 想查反向依赖（谁引了
golang.org/x/net），得自己写awk '{print $2, $1}' | grep 'golang.org/x/net'或用脚本翻转列 - 输出中无版本号的行（如
A B）表示 B 是主模块或本地 replace 模块，此时要回头查go.mod中的replace声明
用 go list -m all 定位模块存在性与状态
这是验证“某个模块是否真被解析进当前构建”的底线依据。它不体现层级，但带关键元信息：
立即学习“go语言免费学习笔记（深入）”；
- 每行末尾的
// indirect表示该模块未被主模块require，只是某条依赖链的副产品 - 含
=>的行说明被replace，例如github.com/sirupsen/logrus v1.9.0 => ./local-logrus，这时实际引用流应以./local-logrus为准，但go mod graph不反映这点 - 不加
-f默认只输出路径+版本，加-json可拿到Indirect、Replace、Dir字段，方便脚本判断模块是否被覆盖或缓存是否就绪 - 若某模块出现在
go list -m all但go mod why -m查不到，大概率是它没被任何import触达，只是go.sum里残留的“幽灵记录”
复杂点在于：引用流不是静态树，而是构建时动态拼合的结果
同一个 go.mod，执行 go build、go test 或 go run main.go 可能触发不同 import 图——test 文件里的 _test 包、// +build 条件标签、甚至 GOOS=js 环境变量都会让依赖集合发生变化。所以没有“唯一正确”的引用流快照，只有针对具体构建动作的上下文快照。
