go.mod中出现不想用的间接依赖是因为go自动记录所有参与构建的依赖，包括被直接依赖引入的间接包；可用replace重定向或exclude彻底禁止其版本参与构建。
为什么 go.mod 里会出现不想用的间接依赖
Go 的模块系统会自动记录所有实际参与构建的依赖，包括你没直接 import、但被某个直接依赖（比如 github.com/some/lib）内部引用的包。这些就是间接依赖，出现在 go.mod 的 // indirect 注释行里。它们通常没问题，但有时会带来冲突：比如某个间接依赖引入了不兼容的 golang.org/x/net 版本，导致你的 HTTP 客户端行为异常；或者它包含你不希望链接进二进制的 CGO 组件。
用 replace 强制替换间接依赖的目标模块
这是最常用也最可控的方式——不是“删除”，而是把有问题的间接依赖指向一个安全版本（甚至空实现）。Go 构建时会优先使用 replace 规则，绕过原本解析出的版本。
- 在
go.mod文件末尾添加：replace github.com/bad/indirect => github.com/good/indirect v1.2.0
- 如果只是想排除（即让 Go 完全忽略它），可指向一个空模块或本地 dummy 目录：
replace github.com/bad/indirect => ./internal/empty
（需确保该路径下有合法的go.mod） -
replace对直接和间接依赖都生效，但只影响当前 module；子模块不会继承，除非显式复制 - 执行
go mod tidy后，原间接依赖仍可能保留在go.mod中（带// indirect），但构建时已不使用它
用 exclude 彻底禁止某模块版本参与构建
当某个间接依赖的特定版本存在严重漏洞（如 CVE），且你无法升级其上游直接依赖时，exclude 是更严格的手段。它会让 Go 拒绝加载被排除的模块版本，哪怕其他依赖声明了它。
- 在
go.mod中写：exclude github.com/vulnerable/pkg v1.0.5
- 注意：必须指定完整模块路径 + 版本号；通配符不支持；多个版本要逐行写
- 如果某个依赖硬编码要求该被排除的版本，
go build会直接失败并报错：require github.com/vulnerable/pkg: version v1.0.5 is excluded -
exclude不影响go list -m all输出，但会改变go mod graph的实际解析结果
小心 go mod edit -droprequire 的副作用
有人尝试用 go mod edit -droprequire=xxx 删除间接依赖行，但这只是从 go.mod 文本中移除那行声明，Go 工具链下次运行 go mod tidy 或构建时，只要该模块仍被实际引用，就会自动加回来。它不能真正“排除”依赖。
- 仅适用于你确认该模块已完全未被任何代码 import（包括嵌套的 vendor 代码、测试文件等）
- 执行后务必运行
go build ./...和go test ./...验证，否则上线后可能 panic：cannot find module providing package xxx - CI 环境中若未清理
go.sum，还可能出现校验失败
真正起效的排除动作，本质是控制模块图的解析路径，而不是编辑文本。replace 和 exclude 是唯二被 Go 工具链尊重的机制，其余操作容易在下次 tidy 时失效。尤其要注意：间接依赖常藏在测试依赖或 init() 函数触发的隐式 import 里，光看 go list -deps 可能漏掉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
