清理Go项目无效依赖需先运行go mod tidy，再结合go list -deps、go mod why等工具验证是否真未使用，区分生产/测试依赖，谨慎处理indirect项，通过CI和pre-commit机制防回归。
Go 项目中残留的无效依赖（即未被代码直接或间接引用，但仍在 go.mod 中声明的模块）会增加构建时间、引入安全风险、干扰依赖审计。清理它们不是简单删掉 require 行，而是需要结合 Go Module 的语义和工具链做安全、可验证的操作。
确认哪些依赖真正“无效”
Go 不像某些语言有显式的“导入即使用”机制——有些依赖可能通过插件式加载、反射、构建标签（//go:build）、或测试专用逻辑间接使用。盲目删除会导致编译失败或运行时 panic。
- 先运行
go mod tidy：它会自动移除未被当前main或启用的build tags下任何包 import 的模块 - 若项目含多个主入口（如 CLI + HTTP server + worker），需分别在对应目录下执行
go mod tidy，或用-modfile指定不同配置 - 检查
go list -deps ./... | grep 'some-module'，确认该模块是否出现在任意包的依赖图中
区分“未使用”与“仅测试使用”
有些模块只在 _test.go 文件中被导入（比如 testify, ginkgo），它们属于 require 块中的 // indirect 或普通条目，但不属于生产依赖。
- Go 1.21+ 支持
go mod tidy -compat=1.21后，go test不再自动拉取测试依赖到主go.mod；老版本建议用go mod edit -droprequire=module/path手动剔除已确认仅用于测试的项 - 更稳妥的做法：保留测试依赖，但在 CI 中用
go list -f '{{.Deps}}' ./... | tr ' ' '\n' | sort -u对比生产构建依赖集，明确划分 scope
自动化清理 + 防回归机制
单次清理容易反弹。建议将清理动作纳入开发流程闭环：
- 在
Makefile或 pre-commit hook 中加入go mod tidy && git diff --quiet go.mod || (echo "go.mod changed, please commit"; exit 1) - CI 流程中添加检查步骤：
go mod verify && go mod graph | awk '{print $1}' | sort -u | wc -l与基线值对比，异常增长即告警 - 使用 goclean 或 mod 等工具辅助识别长期未更新、无 star、高 CVE 风险的“僵尸依赖”
谨慎处理 indirect 依赖和版本漂移
// indirect 标记不代表可删——它表示该模块未被当前模块直接 import，但被其他依赖所依赖。删掉可能导致下游模块解析失败或版本不一致。
- 执行
go mod graph | grep 'target-module'查看谁在拉它；若只有某个已弃用的子模块引用，可考虑升级/替换那个子模块 - 用
go mod why -m module/name追溯引入路径，确认是否因某次要更新导致意外升级了间接依赖 - 必要时用
go mod edit -replace=old@v1.2.3=new@v2.0.0锁定或替换，而非直接删除
基本上就这些。清理无效依赖不是追求 go.mod 行数最少，而是让依赖图真实反映运行时需要——清晰、可控、可审计。每次 go mod tidy 前花两分钟看一眼变化，比事后 debug 依赖冲突省心得多。
