go mod graph 通过输出“依赖者→被依赖者”边列表定位冗余依赖，需配合 grep、awk 等工具定向扫描：查某库引入方用 grep，统计高频中转包用 awk+sort+uniq，过滤标准库和主模块用 grep -v；带 @v0.0.0-... 的多为 replace 引入，需手动核查必要性。
怎么用 go mod graph 快速定位冗余依赖
go mod graph 输出的是原始依赖边列表，每行形如 main-module.com github.com/some/lib@v1.2.3，但它本身不聚合、不过滤，直接看容易眼花。真正有用的是配合 grep 和 awk 做定向扫描：
- 查某个库被谁拉进来：
go mod graph | grep 'github.com/gorilla/mux' - 找间接依赖层级过深的包：
go mod graph | awk '{print $2}' | sort | uniq -c | sort -nr | head -10（统计被引用次数，高频出现的往往是“中转站”） - 过滤掉标准库和主模块：
go mod graph | grep -v '^myproject' | grep -v 'golang.org/'
注意：输出里带 @v0.0.0-... 的通常是 replace 或本地路径引入，这类依赖无法被 go mod tidy 自动清理，得手动检查 go.mod 里的 replace 语句是否还必要。
为什么 go mod why 比依赖图更准地判断“该不该留”
go mod graph 只告诉你“有依赖”，go mod why 才回答“为什么有”。比如你怀疑 github.com/spf13/cobra 是测试工具引入的，运行：go mod why github.com/spf13/cobra，如果输出里出现 test 或 _test 字样，基本就能确认它只在测试中用——这时可加 //go:build !test 构建约束，或把测试依赖挪到 tools.go 文件里隔离。
- 若输出显示依赖链最终止于某个已弃用的 internal 包，说明它只是历史残留，可安全移除
- 若路径里含多个
vendor/或third_party/，大概率是旧版迁移遗留，需核对当前代码是否真调用了对应功能 -
go mod why -m可反向查模块被哪些包需要，适合评估替换成本
替换“全家桶”时怎么避免新依赖悄悄膨胀
换掉 gin 改用 net/http + http.ServeMux 很简单，但容易忽略配套组件：比如原来用 gin 的中间件做日志，换成 zerolog 后，又顺手加了 github.com/rs/zerolog/log —— 这个包会悄悄拉入 github.com/mattn/go-colorable（Windows 控制台着色），而你可能根本不需要颜色输出。
- 替换前先跑：
go list -m all | grep -i 'log\|color\|term'，看当前日志栈实际引入了哪些周边 - 优先选无依赖或仅依赖标准库的替代品：
go.uber.org/zap比logrus少 3 层间接依赖；github.com/google/uuid比某些 ORM 自带 UUID 生成器更轻 - 用
go mod vendor后检查vendor/目录大小，突增说明新库带了没意识到的附属包
CI 中怎么自动化拦截隐性依赖增长
依赖体积不是靠人盯出来的，得靠 CI 卡点。在 GitHub Actions 或 GitLab CI 里加一步：go list -m -json all | jq -r '.Path + " " + .Version' | sort > deps-before.txt，再和上次提交的 deps-before.txt diff。但更关键的是识别“不该存在”的依赖：
- 禁止
gopkg.in/域名（已停更多年，大量 v1/v2 混用） - 拒绝
v0.0.0-开头的伪版本（除非明确是本地 replace） - 对
github.com/coreos/etcd这类已归档项目，强制要求版本 ≥ v3.5.0（v3.4.x 有已知 CVE）
真正难处理的不是显式写的依赖，而是某次 go get 时没加 -u，结果旧版间接依赖卡在 go.sum 里不动，半年后才发现它拖慢了构建——这种得靠定期 go mod verify + go list -m all 对比基线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
