go mod why -m 查不到包是因为该模块未被任何 import 语句实际引用，仅存在于 go.mod 或 go.sum 中；需先用 go list -m all 确认存在，再检查拼写、是否 indirect（加 -m）、是否测试依赖（加 -test），并用 go list -deps 验证是否真被导入。
go mod why -m 查不到包？先确认它是否真被引入
很多情况下 go mod why -m 返回 main: unknown import path，不是命令错了，而是这个模块压根没被任何 import 语句触发过——它只躺在 go.mod 或 go.sum 里，属于“幽灵依赖”。
- 先跑
go list -m all | grep your-module，确认它确实在依赖列表里 - 再检查拼写：大小写、
/v2后缀、/internal路径是否一致 - 如果它是
// indirect标记的，必须加-m；如果是测试专用，得加-test -
go mod why -m只回答“为什么在go.mod中”，不保证该模块参与构建——go list -deps ./ | grep才能验证是否真被 import 过
依赖来源是 proxy、私有库还是本地 replace？看 go list -m -json 的字段
go list -m -json all 输出里的 Replace 和 Dir 字段才是真实线索，比看 go.mod 更可靠，因为环境变量（如 GOPROXY、GOPRIVATE）和 replace 规则会在解析时生效。
-
Replace非空 → 表示被覆盖：值为{"Path": "github.com/foo/bar"}是远程替换，{"Dir": "/path/to/local"}是本地路径 -
Dir指向$GOPATH/pkg/mod/cache/download/...→ 来自 proxy 或公共仓库 -
Dir指向你公司 Git 服务器的克隆路径（如/tmp/gomod-xxx）→ 很可能匹配了GOPRIVATE，跳过了 proxy - 注意：
go list -m all文本输出里末尾的=> ../foo或=> git.example.com/bar就是Replace的简写形式
某个包被多个版本同时拉入？用 go mod graph 找冲突源头
go mod graph 不展示层级，但每行 A B@v1.2.3 是一条确定的依赖边，适合 grep 和人工扫——尤其当 go list -m all 显示同一个包出现两次不同版本时。
- 先定位目标包：
go mod graph | grep 'github.com/sirupsen/logrus' - 观察输出中是否同时存在
logrus v1.8.1和logrus v1.9.0，再分别查谁引的：go mod graph | grep 'v1.8.1$' - 注意：不含版本号的行（如
myproj github.com/sirupsen/logrus）表示该包是主模块或被replace了，需回查go.mod - 别忽略
go mod why -m只返回最短路径——实际可能有多个分支，得结合go list -deps -f '{{.Path}}' . | grep logrus补全
依赖存在但代码完全没用到？靠 go list -f '{{.Imports}}' ./ 对比
有些模块出现在 go list -m all 里，只是因为某旧依赖残留，当前构建根本不需要。这类“死依赖”不会报错，但会拖慢 go mod download、增加供应链风险。
立即学习“go语言免费学习笔记（深入）”；
- 获取所有实际 import 的包路径：
go list -f '{{.ImportPath}} {{.Imports}}' ./ - 提取全部导入项（含嵌套）：
go list -f '{{join .Imports "\n"}}' ./ | sort -u - 对比
go list -m -f '{{.Path}}' all的输出，取差集就是疑似冗余模块 - 谨慎操作：
go mod tidy通常能自动清理，但如果项目用了// +build ignore或go:embed生成代码，可能误删——先手动验证 import 是否真消失
replace 掩盖、又被 GOPRIVATE 绕过 proxy 的私有模块，它们的 Dir 路径藏在缓存深处，且 go mod graph 不显示原始路径。这时候必须把 go list -m -json 和 go env 输出一起看，否则很容易对着错误的“来源”调试半天。 
