用 go list -m all 查依赖树需配合 -f 模板或 go mod graph；go mod tidy 拉意外版本因 MVS 自动选最低兼容版；vendor 后仍联网因未设 -mod=vendor 或缺 go.mod；剔除未用依赖需筛直接依赖并测试注释或用 gofnd 等工具。
如何用 go list 查看当前项目的依赖树
直接运行 go list -m all 可以列出所有模块级依赖（含间接依赖），但默认是扁平化列表，看不出层级关系。真正要看清依赖树，得加 -f 模板配合递归：运行 go list -f '{{.Path}}: {{.DependsOn}}' all 不实用，更可靠的是用 go mod graph 输出有向图，再配合 grep 或 dot 可视化。常见错误是只跑 go list -m 忽略 -u 参数，导致看不到可升级版本；需要检查更新时应加 -u -m。
为什么 go mod tidy 有时会拉取意外版本
根本原因是 go.mod 中未显式约束间接依赖的版本，而 tidy 会按最小版本选择（MVS）自动补全满足所有直接依赖要求的最低兼容版本。比如 A 依赖 B v1.2.0，B 又依赖 C v1.5.0，但你的项目里另一处直接引入了 C v1.3.0，tidy 就可能锁定 C v1.5.0 —— 因为它要同时满足 A 和你显式写的 C 版本。解决办法是：用 go mod edit -require=github.com/x/y@v1.3.0 强制指定，或在 go.mod 末尾加 replace 临时覆盖。
go mod vendor 后为什么编译仍联网下载
vendor 目录只是镜像，并不改变模块解析逻辑。如果 go build 时仍尝试访问远程仓库，通常是因为：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 本地
GOFLAGS包含-mod=readonly或未设-mod=vendor - 某依赖的
go.mod文件缺失（尤其私有模块打 zip 包时漏了该文件） - 执行命令时不在 module 根目录，导致 Go 无法识别 vendor 存在
go build -mod=vendor -x，观察输出中是否还有 git 或 fetch 行。注意 vendor 不解决 checksum 验证问题，go.sum 仍必须存在且完整。
如何定位和剔除未使用的依赖包
Go 官方工具链不提供“未使用 import”检测（因为 import 可能仅用于 init 或嵌入 interface），但可分两步逼近：先用 go list -f '{{if not .Indirect}}{{.Path}}{{end}}' all 筛出直接依赖；再逐个注释 import 并运行 go build -a -v，观察是否报错。更高效的是用 gofnd（第三方）或 go-unused 工具扫描 import 语句实际调用情况。容易被忽略的是测试文件（*_test.go）引入的依赖，它们不会出现在 all 列表中，需单独跑 go list -f '{{.ImportPath}}' ./... | grep test 检查。
立即学习“go语言免费学习笔记（深入）”；
