go-callvis不能直接看出间接调用链，它仅分析当前包内显式调用关系，不解析跨模块间接依赖、interface实现、reflect或plugin等动态调用。
go-callvis 能不能直接看出间接调用链
不能。它只画出当前包内函数的显式调用关系，不解析跨模块的间接依赖——比如 service.New() 返回一个接口，实际实现来自 github.com/xxx/impl，go-callvis 不会把 impl 包里的方法画进来，除非你手动 -focus 到那个包并指定 -algo static。它默认只分析 import 语句能静态推导出的调用，对 interface{}、reflect、plugin 或 callback 注入完全不可见。
golangci-lint 怎么暴露隐藏的间接依赖
靠 staticcheck 和 unused 配合识别“看似没用、实则被间接触发”的依赖：
-
staticcheck的SA1019规则能报出你代码里没直接调用、但某个依赖包内部用了已弃用 API 的情况——说明该依赖正在被间接执行 -
unused会标记未使用的import _ "xxx"，但如果你删了它，go build -a -v报错，就证明它通过 init() 或全局注册被间接引用 - 运行
golangci-lint run --no-config --enable=unused,staticcheck ./...，再结合go mod graph | grep xxx看谁在拉这个包
为什么 go mod why -m xxx 有时查不到调用路径
go mod why -m 只回答“为什么这个模块在 go.mod 里”，不回答“谁在 runtime 调用它的函数”。常见失效场景：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 依赖通过
init()注册（如数据库驱动import _ "github.com/lib/pq"），why查不到调用方，只显示“required by main” - 使用了
plugin或reflect.Value.Call动态调用，编译期无法静态追踪 - 模块被 replace 或 exclude 后，
why输出路径断裂，得先跑go mod graph过滤再人工追
真正要砍掉间接调用，得动代码结构
工具只能提示，删不掉隐式依赖。关键动作是打破“靠 import 自动带入”的惯性：
- 把第三方库的调用封装进本地接口，比如定义
type Logger interface { Info(...any) }，而不是直接import "github.com/sirupsen/logrus" - 用函数选项（functional option）替代全局 init 注册，把依赖注入从隐式变成显式参数
- 检查所有
import _，确认每个都有对应sql.Register或encoding/json.Register类调用；没有的，就是冗余
间接调用最难清理的不是命令怎么敲，而是得区分“这个包真没被用”和“它被 init 或反射悄悄拉起来了”——后者必须看代码逻辑，工具只给线索，不给结论。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
