go mod tidy 不是“排毒工具”，它只同步 go.mod 与实际 import 的包，无法识别恶意、废弃或高危依赖；真正“排毒”需结合 go vulncheck、grep、go mod graph 和 go mod edit -droprequire 等手动组合操作。
go mod tidy 不是“排毒工具”，它不会主动识别或删除所谓“非法”依赖包——它只做一件事：让 go.mod 与源码中实际 import 的包保持一致。 所谓“非法包”（如恶意包、废弃包、高危漏洞包）必须靠人工判断或专用扫描工具发现，go mod tidy 对它们完全无感。
为什么 go mod tidy 无法识别恶意或高危包
它的逻辑极其朴素：只要某个模块出现在任一 .go 文件的 import 语句里（包括 import _ "xxx"），就认为它是“被需要的”，就会保留在 go.mod 中；反之，若没被任何 import 引用，且未被其他已用依赖传递引入，才会被删。
这意味着：
- 一个带后门的
github.com/bad/pkg，只要你代码里写了import "github.com/bad/pkg"，go mod tidy不仅不删，还会帮你下载、加进go.mod、更新go.sum - 一个已被标记为
Deprecated的包，只要还在 import 列表里，tidy 就当它合法 - 一个在
go vulncheck中报CVE-2024-xxxxx的包，tidy 完全看不见 CVE
真正能“排毒”的三类操作
要清理非法/高危/废弃依赖，得组合使用以下手段，不能只靠 go mod tidy：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
先定位可疑包：运行
go list -m all | grep -E "(bad|malicious|unmaintained)"，或更可靠地用go vulncheck -v ./...扫描已知漏洞 -
确认是否真被使用：用
grep -r 'github.com/bad/pkg' --include='*.go' .查有没有 import；若没找到，再查go mod graph | grep 'bad/pkg'看是否是某合法包的间接依赖 -
手动干预移除：若确认该包既无 import、又无传递依赖，可安全执行
go mod edit -droprequire github.com/bad/pkg，再跑go mod tidy收尾；若它被其他包依赖，就得先升级/替换那个上游包
go mod edit -droprequire 是唯一能绕过 import 判断的强制删除方式
go mod tidy 永远尊重 import 语句，但 go mod edit -droprequire 是直接编辑 go.mod 文件、删掉指定 require 行。它不校验是否被引用，也不管是否破坏构建——后果自负。
典型适用场景：
- 你明确知道某个包是旧版间接依赖残留（比如
A → B v1.0，但你手动 require 了B v2.0，而 v2.0 实际未被任何路径加载） - CI 流程中需硬性阻断某恶意域名下的所有包（如
go mod edit -droprequire evil.io/malware） - 想临时隔离一个有争议的包，观察构建和测试是否仍通过
⚠️ 注意：go mod edit -droprequire 后必须立即运行 go build ./ 和 go test ./，否则极易在后续编译时报 import not found 或运行时 panic。
真正的“排毒”不是靠一个命令自动完成的，而是靠 go vulncheck 找问题、go mod graph 看路径、grep 验证引用、最后用 go mod edit -droprequire 或 replace 精准手术——任何跳过验证环节的 tidy 或 droprequire，都可能把项目拖进更隐蔽的坑里。
