Go依赖分析需结合go list -m all、go mod graph和go list -f '{{.Deps}}'：前者查最终模块快照，后者定位路径与包级依赖，注意间接依赖、版本冲突及裁剪机制影响。
Go 没有内置的“依赖图可视化”命令，但 go list 和 go mod graph 足够查清绝大多数依赖来源和冲突点——关键在于用对参数、理解输出含义。
用 go list -m all 查看当前模块所有直接/间接依赖
这是最常用也最稳妥的起点，它列出的是 go.mod 解析后的最终依赖快照（含版本号），不受本地 vendor 或缓存干扰：
-
-m表示操作模块（module）而非包（package）；all是特殊模式，展开全部依赖树 - 输出中带
// indirect标记的，说明该模块未被当前项目直接import，而是被其他依赖引入的 - 如果某个模块出现多次不同版本（比如
github.com/some/pkg v1.2.0和v1.3.0），说明存在版本冲突，需要进一步定位谁在拉取旧版
用 go mod graph 定位具体依赖路径和版本冲突源头
go mod graph 输出的是有向边列表（A B@v1.2.0 表示 A 依赖 B 的 v1.2.0），适合 grep 或管道处理：
- 查某包被谁引入：
go mod graph | grep 'github.com/some/pkg'，结果里左边是它的直接引用者 - 查某模块是否被重复引入不同版本：
go mod graph | awk '{print $2}' | grep 'github.com/some/pkg@' | sort | uniq -c - 注意：该命令不自动 resolve 版本，输出可能包含已被
replace或exclude掩盖的边，需结合go list -m all交叉验证
用 go list -f '{{.Deps}}' <package></package> 查单个包的 import 依赖（不含模块信息）
这个命令针对的是 Go 包层级（不是模块），适合调试编译失败时 “找不到符号” 或 “循环 import” 类问题：
立即学习“go语言免费学习笔记（深入）”；
-
go list -f '{{.Deps}}' ./cmd/myapp输出该命令入口依赖的所有包路径（如[fmt encoding/json github.com/some/lib]） - 它不显示版本，也不区分是 direct 还是 indirect，仅反映源码中
import语句的静态关系 - 若输出为空或报错
no required module provides package，说明该包未被go.mod管理，可能是vendor目录未启用或路径错误
常见陷阱：为什么 go mod graph 看不到你 expect 的依赖？
不是命令失效，而是 Go Module 的依赖裁剪机制在起作用：
- 构建时未实际 import 的模块，即使写在
go.mod里，也可能被go mod tidy清掉——先运行go mod tidy -v看清理日志 - 条件编译（
// +build）或测试专用依赖（只在*_test.go中 import）不会出现在主模块图中，要用go list -f '{{.Deps}}' ./... | grep单独扫测试包 -
replace会改写依赖目标但不改变图结构显示，比如replace github.com/old => ./local/fork后，go mod graph仍显示old，但实际编译走的是本地路径
依赖分析真正难的不是命令怎么敲，而是把 go list -m all 的版本列表、go mod graph 的边关系、以及你代码里真实的 import 三者对上——尤其当项目用了多模块 workspace 或大量 replace 时，少看一行输出就可能误判根源。
