用go mod graph定位冗余依赖路径：执行go mod graph | grep 'module'查看所有引入路径，识别多版本共存及上游依赖；配合go list -m all和go mod why追溯源头，再通过replace或显式require统一版本。
怎么用 go mod graph 定位冗余依赖路径
go list -m all 只给你一张扁平列表，看不出谁在重复拉同一个包、谁偷偷带进来了高版本。真正要揪出“拖慢构建”或“引发冲突”的模块，得靠 go mod graph 管道过滤。
比如你怀疑 github.com/gorilla/mux 被多个路径引入，运行：
go mod graph | grep 'github.com/gorilla/mux'
输出会显示每条引入路径，例如：
main-module github.com/gorilla/mux@v1.8.0 github.com/astaxie/beego github.com/gorilla/mux@v1.7.0 github.com/labstack/echo/v4 github.com/gorilla/mux@v1.8.0
这说明它被三个不同依赖分别拉入，且版本不一致——这就是潜在冲突源。
立即学习“go语言免费学习笔记（深入）”；
- 别只看最后一行，重点查上游是谁在 require 它；
- 配合
go list -f '{{.Path}} {{.DependsOn}}' all追一层依赖关系； - 如果某模块出现 5 次以上，大概率是可收敛的“公共依赖”，适合用
replace或显式require统一版本。
怎么安全地统一间接依赖版本
indirect 模块不是垃圾，而是 Go 模块机制诚实记录了“谁真用了它”。但放任不管，容易让日志库、HTTP 客户端等关键组件悄悄升级，改掉默认行为（比如加了 trace header）。
想锁定子依赖，不能靠在自己 go.mod 里加 require ——Go 不认这种“越级要求”。必须用 replace 或 exclude 干预解析结果：
- 锁定版本：在
go.mod末尾加replace github.com/sirupsen/logrus => github.com/sirupsen/logrus v1.9.0； - 阻止危险版本：
exclude github.com/bad/pkg v1.20.0（适用于已知 crash 的 patch 版本）； - 验证是否生效：
go list -m all | grep logrus看输出是否变成你指定的版本和来源； -
replace指向本地路径（如./fix）仅限开发，CI 会失败，上线前必须删掉或换为真实 tag。
怎么判断某个 import 其实没被用到
Go 工具链不分析 import 是否被实际调用，因为 init()、嵌入接口、测试文件里的引用都是合法但静默的。只能逼近判断：
- 先筛出直接依赖：
go list -f '{{if not .Indirect}}{{.Path}}{{end}}' all； - 逐个注释
import _ "xxx"或普通import，再跑go build -a -v；报错才说明还在用； - 别漏掉测试文件：
go list -f '{{.ImportPath}}' ./... | grep test，很多未用依赖藏在*_test.go里； - 第三方工具如
gofnd或go-unused可扫 AST，但对泛型、反射调用识别不准，有 false negative 风险。
vendor 后还联网？三步定位原因
执行了 go mod vendor，go build 却仍尝试 git fetch 或 GET https://，说明 vendor 没起作用。关键检查点只有三个：
- 构建命令是否加了
-mod=vendor？只运行go mod vendor不够，go build默认仍走网络； - 当前目录是否为 module 根？即含
go.mod文件；否则 Go 忽略vendor/目录； - 运行
go build -mod=vendor -x，观察输出里有没有远程请求行；如果有，大概率是某依赖的go.mod缺失或校验失败，Go 回退到网络拉取。
真正的复杂点不在命令怎么敲，而在于某个看似无关的 indirect 模块，在你没注意的时候替换了接口行为——比如 JSON 库升级后把 omitempty 的空数组处理逻辑改了。这种问题不会报错，但会让线上数据格式突变。定期用 go mod graph 结合 git blame go.mod 追变更源头，比盲目删依赖更可靠。
