查清包依赖来源需用go mod graph | grep定位引入者，或go list -deps | grep看准确版本；间接依赖应通过go mod why -m分析必要性，优先升级/替换上游而非滥用replace/exclude。
Go模块依赖过多，不是靠删 go.mod 里的行就能解决的；真正有效的方式是定位“谁引入了谁”、识别间接依赖中的冗余路径、再用最小化重构手段切断非必要依赖链。
怎么查清一个包到底被谁拉进来的
Go 没有内置的“依赖溯源图”，但 go mod graph 加上文本处理能快速定位。比如想查 github.com/sirupsen/logrus 是被哪个主依赖带进来的：
go mod graph | grep 'logrus' | grep -v 'golang.org'
输出类似 myproject github.com/sirupsen/logrus@v1.9.3 表示直接依赖，而 github.com/astaxie/beego github.com/sirupsen/logrus@v1.8.1 表示是 beego 拉进来的。
- 注意
go mod graph输出不含版本号时，说明该模块未被实际解析（可能被 replace 或 exclude 掩盖） - 用
go list -deps -f '{{.Path}} {{.Module.Version}}' . | grep logrus可看到更准确的版本来源 - 如果某包只在测试中使用（如
testify），应确保它只出现在//go:build test文件里，避免污染主依赖树
replace 和 exclude 不是万能解药
replace 和 exclude 能压制依赖冲突或跳过有问题的版本，但无法减少最终构建时加载的模块数量。它们只是重写解析规则，不改变依赖图结构。
-
exclude只在go build阶段生效，go list -m all仍会列出被 exclude 的模块 -
replace若指向本地路径，会导致go mod tidy失去对该模块版本的控制权，CI 环境容易出错 - 滥用
replace可能掩盖真正的兼容性问题，比如把 v2+ 的模块强行 replace 成 v1，运行时 panic 很常见
如何安全地移除间接依赖
间接依赖（indirect）出现在 go.mod 中，通常是因为某个直接依赖的 go.mod 声明了它。要删掉它，必须让它的上游不再需要它——要么升级上游，要么替换上游，要么自己实现轻量替代。
- 先运行
go mod graph | grep ' xxx '确认该间接依赖是否真被任何包 import（有些只是旧版本残留） - 用
go mod why -m github.com/xxx/yyy查看“为什么需要它”，输出main表示直接 import，否则显示具体路径 - 如果它是某个大包（如
github.com/spf13/cobra）的子依赖，而你只用其中一两个函数，考虑手写等效逻辑（比如只用cobra.Command.Flags()，就不用整个 cobra） - 对 HTTP 客户端类间接依赖（如
golang.org/x/net/http2），检查是否真的用了 HTTP/2 特性；没用的话，可设GODEBUG=http2client=0运行时禁用，但不会减少编译依赖
构建时真正影响体积和速度的是 require 而非 indirect
go build 的实际加载行为取决于 require 块中的模块，indirect 标记只是提示“这个模块没被当前 module 直接 import”。但只要它被某个 require 模块 import 过，就会参与编译。
-
go mod tidy -compat=1.16可强制降级模块版本，有时能砍掉新版引入的额外依赖（如某些 v2+ 包新增了golang.org/x/exp） - 用
go list -f '{{.Deps}}' std | tr ' ' '\n' | sort -u | wc -l对比标准库依赖数，能粗略判断你的模块是否异常臃肿 - 最狠但有效的办法：新建空模块，逐个
go get你真正用到的包，再go mod tidy—— 很多项目其实只用到了原始依赖的 30%
依赖精简不是越少越好，而是让每一项 require 都有明确的、不可绕过的用途。最容易被忽略的是测试工具链和生成代码工具（如 swag、mockgen）悄悄混进主 go.mod，它们应该用独立的 tools.go 文件隔离。
