go mod why -m github.com/sirupsen/logrus 可查该模块被谁引入；若输出“(main module does not need...)”，则为残留；go mod tidy 不删间接依赖，需结合 grep、go list、go mod graph 等验证后手动清理并测试。
go mod why 怎么查一个包为什么还在 go.mod 里
直接运行 go mod why -m github.com/sirupsen/logrus，它会告诉你这个模块被谁拉进来的——不是“有没有用”，而是“谁 import 了它或它的子包”。输出里如果出现 (main module does not need module github.com/sirupsen/logrus)，说明项目代码（含所有 _test.go）里没有任何地方触发过这个模块的 import，它大概率是残留。
- 加
-m强制按模块查，避免因输错子包路径而漏掉结果 - 不加
-m查具体包路径（比如go mod why golang.org/x/net/http2），能定位到哪一行import真正触发了依赖，更准 - 如果输出为空或只有一行
main，说明它没被任何依赖链引用，go mod tidy下次就会删掉它
为什么 go mod tidy 没删掉那个“明明没用”的包
go mod tidy 不会删掉间接依赖（即带 // indirect 标记的 require 条目），哪怕你代码里完全没 import 它——只要某个已被引用的模块声明了它为依赖，tidy 就认为它“可能有用”。真正会被删的，是既没被 import、又不是任何已存在模块的间接依赖的条目。
- 常见陷阱：测试文件（
*_test.go）里 import 了工具库（如github.com/stretchr/testify），导致其依赖链里的包也被保留在go.mod中 - 条件编译块（如
//go:build windows）里的 import，当前构建环境不满足时，tidy可能忽略，但该包仍被保留 - 隐式加载（
import _ "database/sql"或驱动注册）不会被tidy感知，需人工确认是否必须
怎么安全地清理间接依赖并验证效果
不能靠猜，得组合命令交叉验证。先看它是不是真没人要，再动手，最后跑一遍构建和测试。
- 查依赖图：
go mod graph | grep logrus，看哪些模块在拉它；再用go list -f '{{.Deps}}' ./... | tr ' ' '\n' | grep logrus确认是否出现在任意包的依赖列表中 - 搜代码：
grep -r "import.*logrus" . --include="*.go"，特别注意internal/和test目录 - 执行
go mod tidy -v，观察输出里有没有 “removing unused requirement” 字样；再检查go.mod是否还剩logrus - 清理后必须跑：
go build ./...+go test ./...，尤其关注 CI 是否用不同GOOS/GOARCH构建
replace 和 indirect 标记容易误判的两个点
// indirect 不等于“可删”，它只是标记“非主模块直接 import”；而 replace 会让 go mod why 的路径变短甚至断掉，掩盖真实依赖来源。
立即学习“go语言免费学习笔记（深入）”；
- 如果你在
go.mod里写了replace golang.org/x/net => ./vendor/x/net，go mod why golang.org/x/net可能只显示main，而不是原本的 gin → yaml → net 路径 -
go list -m all | grep indirect列出所有间接依赖，但其中有些是生产必需（比如google.golang.org/grpc的底层依赖），盲目删会导致运行时 panic - 想确认某
// indirect包是否真可删？临时注释掉它，再跑go mod tidy -v—— 如果 tidy 自动补回，说明上游模块仍需要它
最常被忽略的是测试依赖和构建标签控制的导入，它们让“是否使用”变成上下文敏感问题。每次清理后，别只信 tidy 的输出，一定要在目标平台和完整测试集下验证。
