go mod tidy 会拉取不相关模块，因其递归解析所有依赖的 go.mod 中 require；常见原因包括临时工具引入、ci 隐式加载、replace/exclude 干扰。
为什么 go mod tidy 会拉取不相关的模块？
Go 的模块依赖是传递性收敛的，go mod tidy 不只扫描当前包的 import，还会解析所有依赖模块的 go.mod 中声明的 require，并递归合并。如果你的某个间接依赖（比如 github.com/some/lib v1.2.0）自身依赖了 golang.org/x/net，即使你代码里没直接 import 它，它也会被写入你的 go.mod。
常见诱因包括：
- 本地开发时临时
go get过某个工具（如golang.org/x/tools/cmd/stringer），它带入了整套x/生态 - CI 环境中执行了
go list -m all或其他模块发现命令，触发隐式加载 - 某依赖模块的
go.mod里声明了未实际使用的replace或exclude，干扰了依赖图计算
如何精准控制 indirect 依赖的版本？
indirect 标记本身只是 Go 模块系统对“非直接 import 引入但又必需”的一种标注，它不阻止你手动锁定版本。真正起作用的是 go.mod 中的 require 行 —— 只要存在，就会参与构建和校验。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go get some/module@v1.5.3显式升级/降级，即使它当前是indirect，Go 也会把它提到主require区并去掉// indirect - 若只想固定版本但不引入 import，可加空导入：
_ "some/module"，再运行go mod tidy，它就变成直接依赖 - 检查是否真需要该模块：用
go mod graph | grep module/name查它被谁拉入；再用go list -f '{{.Deps}}' your/main/package | grep module/name确认调用链
跨包 circular import 报错怎么快速定位？
Go 编译器报错 import cycle not allowed 时，错误信息末尾通常只显示最外层两个包，但真实环可能更深。靠肉眼查 import 语句效率极低。
更有效的方式是：
- 运行
go list -f '{{.ImportPath}}: {{.Deps}}' ./... > deps.txt导出全量依赖关系，再用脚本或文本工具搜索循环路径 - 用
go mod graph输出有向图，配合grep和awk追踪：例如go mod graph | awk -F' ' '$1=="a/b" {print $2}' | xargs -I{} sh -c 'echo {}; go mod graph | grep "^{} "' - 临时删掉疑似“胶水包”（如
pkg/common）的import，看是否还报错 —— 如果不报了，说明它是环的关键节点
根本解法不是绕开，而是拆出接口定义到独立包（如 pkg/interface），让上下游都依赖接口而非具体实现。
vendor 目录下为什么有些包没被收录？
go mod vendor 默认只 vendoring 构建时实际用到的包，即满足「出现在 go list -f '{{.Deps}}' . 结果中」且「不是标准库」的模块。它不会把 go.mod 里所有 require 都拉进来。
典型遗漏场景：
- 测试专用依赖（如
github.com/stretchr/testify）只在*_test.go中 import，而你运行的是go mod vendor（非go mod vendor -o ./vendor加测试标志） - 构建 tag 控制的依赖（如
// +build integration）在默认构建环境下不可见 - 某些工具类模块（如
golang.org/x/lint）被go list视为 “main module only”，不进入 vendor
如果必须全部 vendor，可用 go mod vendor -v 查日志确认哪些被跳过，再配合 GOOS= GOARCH= go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./... 手动补全。
go.work 文件的存在 —— 它会让多模块工作区覆盖单个 go.mod 的行为，导致 go mod tidy 结果与预期不符，却不会报错。只要项目根目录下有 go.work，就得先确认它的 use 列表是否包含当前模块。 
