go list -m all 输出扁平依赖列表，不体现层级；go mod graph 生成有向边依赖图，可转树形；go mod why -m 查单模块引入路径；gomodtree 提供近似树形视图，但依赖本地缓存。
go list -m all 能看到依赖列表，但不是树形结构
直接运行 go list -m all 会输出所有模块（含间接依赖）的扁平列表，包括版本号和替换状态，但它不体现层级关系。比如 github.com/gin-gonic/gin v1.9.1 下面用了哪个 golang.org/x/net 版本，得自己肉眼比对——这在中大型项目里很快失效。
用 go mod graph 输出原始依赖图，再用工具转成树
go mod graph 输出的是有向边格式（A B 表示 A 依赖 B），适合程序处理。实际使用时推荐搭配 dot 或轻量脚本：
- 装 Graphviz：
brew install graphviz（macOS）或apt install graphviz（Ubuntu） - 生成 PNG：
go mod graph | dot -Tpng -o deps.png
- 如果只想看当前 module 的直接依赖，加过滤：
go mod graph | grep "^$(go list -m) " | cut -d' ' -f2
注意：go mod graph 不处理 replace 和 exclude，若项目里用了 replace github.com/some/lib => ./local-fix，输出里仍显示原始路径，容易误判。
go mod why -m 按需查某模块为何被引入
当发现一个陌生依赖（比如 gopkg.in/yaml.v2）出现在 go list -m all 中，又不确定谁拉进来的，用：
go mod why -m gopkg.in/yaml.v2
立即学习“go语言免费学习笔记（深入）”；
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
它会从主模块出发，找出一条最短的依赖路径（如 main → github.com/spf13/cobra → github.com/spf13/pflag → gopkg.in/yaml.v2）。这个命令不显示全部路径，只给一个典型链路，但足够定位“幽灵依赖”来源。
第三方工具 gomodtree 更接近真实树形视图
原生命令都不直接支持缩进树形输出，gomodtree 是目前最贴近需求的 CLI 工具：
- 安装：
go install github.com/icholy/gomodtree@latest
- 运行：
gomodtree
（默认从当前 module 展开）或gomodtree github.com/your-org/your-app
- 支持过滤：
gomodtree | grep -E "(gin|sql)"
它会把 replace 和 indirect 标注出来，但要注意：它解析的是 go.sum 和模块缓存，若本地没完整下载过所有依赖（比如 CI 环境刚拉代码），可能漏掉部分间接依赖。
依赖树不是静态快照——go build、go test 甚至 go run 都可能触发隐式加载，导致 go list -m all 和实际编译时用的模块不一致。真正要确认某个构建用了什么版本，得看 go version -m your-binary 输出的嵌入模块信息。
