go mod tidy 不会删除无代码路径调用的间接依赖，因它仅同步 import 与 require；可用 go mod graph 结合 awk、sort、comm 等命令识别并清理未被引用的模块。
为什么 go mod tidy 有时删不干净依赖？
因为 go mod tidy 只保证当前 import 语句和 require 声明的一致性，它不会主动清理那些被间接引用（// indirect）但实际已无任何代码路径调用的模块——尤其当本地 go.sum 或缓存中残留旧版本、或存在未提交的 go.mod 修改时，脏数据就悄悄留下来了。
用 go mod graph 找出真正没被用到的模块
这是最直接的“溯源”手段：它输出所有模块间的依赖关系图，人工或脚本过滤掉没有入度（即没有任何模块 import 它）的叶子节点，就是可安全剔除的目标。
- 运行
go mod graph | awk '{print $2}' | sort -u | grep -v 'your-module-name' > all-deps.txt提取所有被依赖的模块路径 - 再用
go list -m all | grep -v 'your-module-name' | grep -v 'std' > all-modules.txt获取当前声明的所有模块 - 用
comm -13 得到只在 <code>go.mod里却未出现在依赖图中的模块
强制刷新 + 清理缓存才能真正“重置”依赖状态
仅改 go.mod 文件或执行 go mod tidy 不足以清除 GOPATH/GOPROXY 缓存里的旧版本记录，这些残留会导致后续构建仍拉取错误版本，看起来像“删不干净”。
- 先执行
go clean -modcache彻底清空本地模块缓存 - 再删掉
go.sum（不是必须，但能避免校验冲突），然后运行go mod tidy -e（-e让它继续处理其他错误而非中断） - 如果项目使用私有模块，确认
GOPROXY设置不含direct以外的不可信代理，否则可能缓存了带污染的 checksum
CI/CD 中要防自动注入的隐式依赖
很多 CI 流水线会在构建前执行 go get ./... 或类似命令，这会把测试文件、example 目录甚至 _test.go 里的 import 全部纳入依赖，导致生产 go.mod 混入开发期才需要的包。
- CI 中应统一用
go mod tidy -compat=1.21（按目标 Go 版本约束解析行为） - 禁止在
go.mod里保留// indirect标记的模块，除非明确知道它是 transitive 且无法绕过（比如某些 Cgo 依赖） - 检查
go list -deps -f '{{if not .Indirect}}{{.Path}}{{end}}' ./...输出，确保只有主模块显式 import 的路径出现
真正难的不是删掉某一行 require，而是确认那个模块真的不再参与任何编译单元的符号解析——哪怕一个未导出的 init() 函数，都可能让删除变成 runtime panic。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
