go mod graph 显示的依赖与 import 不一致，因为它反映模块级依赖拓扑，包含间接依赖、//go:embed、//go:build 触发的模块及 replace 前原始路径，而非仅源码中显式 import 语句。
go mod graph 为什么显示的依赖和 import 不一致
因为 go mod graph 输出的是模块级依赖拓扑，不是源码 import 语句的直接映射。它包含所有间接依赖、//go:embed 引用、//go:build 条件编译触发的模块，甚至 replace 规则生效前的原始路径。
常见错误现象：go mod graph | grep github.com/foo/bar 看到某模块在图里，但项目里根本没写 import "github.com/foo/bar" —— 很可能它是被某个依赖的 go.mod 显式 require 的，或是通过 replace 拉进来的。
- 运行
go mod graph后加grep "^$(go list -m) "可过滤出主模块的直接下游依赖 -
go mod graph不处理replace和exclude，输出仍是原始模块名（如github.com/foo/bar@v1.0.0），即使你本地已replace成./local - 想查“谁引入了这个模块”，不能只靠
go mod graph正向看，得配合go mod why -m或手动grep -E '→.*pkg|pkg →'扫描回边
go mod why -m 查不到包时该怎么做
go mod why -m 只回答“这个模块为什么出现在 go.mod 中”，但它不保证该模块被当前构建实际用到。如果返回 main: unknown import path，大概率是这个包没被任何 import 语句触达，只是残留在 go.sum 或旧版 go.mod 里。
先确认它是否真实参与构建：
立即学习“go语言免费学习笔记（深入）”；
- 运行
go list -f '{{.Imports}} {{.Deps}}' ./，检查输出里有没有该包路径 - 拼写必须完全一致：大小写、
v2后缀、/internal路径都不能错 - 如果是
indirect依赖，一定要加-m参数；查测试依赖要额外加-test - 执行
go mod tidy后再试 —— 很多“幽灵依赖”其实是旧版本残留，tidy会清理掉未被任何 import 触达的模块
隐式依赖常藏在哪几类代码里
除了显式 import，Go 的构建系统会因以下代码把模块拉进来，且不报错、不提示：
-
//go:embed：哪怕只 embed 一个文件，对应模块也会进依赖图，go mod tidy会保留它 -
//go:generate：生成代码如果 import 了某个包，那个包就算隐式依赖；更麻烦的是生成代码本身可能反向 import 原包，引发循环 - _test.go 文件：测试文件的
import也参与构建期依赖分析，容易和生产代码形成隐蔽环路 - 条件编译标签（
//go:build）：不同构建 tag 下依赖路径不同，go mod graph默认按 all tags 展开，可能包含你当前没启用的分支依赖
排查时别只盯 .go 文件，grep -r "go:embed\|go:generate\|go:build" . 是更快的入口。
可视化依赖图时 Graphviz 容易踩的坑
用 go mod graph | dot -Tpng -o deps.png 生成图看起来很直观，但实际中节点重叠、文字过长、重复子树挤成一团是常态，反而掩盖问题。
- 节点名带版本号（如
golang.org/x/net@v0.14.0）导致文本过长，先用sed 's/@[^ ]*//g'清洗再绘图 - 默认 layout 引擎（dot）在依赖多时布局混乱，换成
fdp或加-Gsplines=ortho参数能改善连线可读性 - Graphviz 不自动折叠重复子树，比如多个包都依赖
golang.org/x/sys，图里会出现十几个相同节点 —— 这不是 bug，是它忠实反映依赖事实，但人工识别成本高 - CI 环境首次运行可能缺缓存，
gomodtree或go mod graph会漏掉部分间接依赖，先跑go mod download再分析
真正关键的不是图有多漂亮，而是能否快速定位那条不该存在的边 —— 比如 service → infra/db → service 这种回边，往往就藏在一行 //go:embed 或一个测试文件里。
