最可靠方法是运行 go build -v ./... 观察构建日志中未显式引用却参与构建的包，并通过注释 import 后执行 go test ./... 验证是否引发未定义或类型错误；需特别注意空白导入（_ "xxx"）触发的 init() 依赖。
如何识别项目中真正未使用的 import 包
Go 编译器本身不会报错未使用的 import，但 go build 和 go test 会直接拒绝编译——这是最可靠的判断依据。不过，有些包看似“没被调用”，实则通过 init() 函数、类型注册（如 database/sql 驱动）、或嵌入式接口间接生效。
推荐分两步验证：
- 运行
go build -v ./...观察哪些包出现在构建日志里但没被显式引用； - 临时注释掉某个
import后执行go test ./...，若测试失败或 panic 提示 “undefined: xxx” 或 “cannot use yyy (type ...) as type...”，说明它被隐式依赖； - 特别注意带空白导入（
_ "github.com/xxx/yyy"）的包，它们通常只为触发init()，删掉前务必确认其作用（比如_ "github.com/lib/pq"是为注册 PostgreSQL 驱动）。
使用 go mod tidy 是否安全？它会误删必需依赖吗
go mod tidy 只移除 go.mod 中存在、但当前模块及所有依赖中**完全未被 import 的模块**，它不分析运行时行为，也不触碰 vendor 或本地 replace。因此它不会误删被 _ 导入、或通过反射/插件机制加载的依赖。
但它有局限：
立即学习“go语言免费学习笔记（深入）”；
- 如果某依赖只在
build tag下启用（如//go:build integration），而你默认运行go mod tidy（无 tag），它会被当作未使用而删除； - 如果项目含多个 main 包（如 CLI + server + migration），且分散在不同子目录，需确保在 module 根目录下执行，并覆盖全部
./...路径，否则 tidy 可能遗漏某些分支的依赖； - 执行前建议先
git status确认没有未提交的改动，避免 tidy 后go.mod和go.sum变更难以回溯。
如何检查间接依赖（require … indirect）是否可删
go mod graph 是关键工具。运行 go mod graph | grep 'unwanted-module' 可查清谁引入了它；再结合 go list -deps -f '{{.ImportPath}} {{.Indirect}}' . | grep true 列出所有间接依赖及其来源。
常见可删场景：
- 某个间接依赖版本明显高于直接依赖所需（如直接依赖 v1.2.0，却拉了 v2.5.0），可能是其他模块强指定导致，可用
go mod edit -droprequire手动清理后go mod tidy修复； - 同一模块多个版本共存（如
golang.org/x/net v0.7.0和v0.14.0），优先保留高版本并确认所有依赖兼容，再删低版本； - 某些测试专用库（如
github.com/stretchr/testify）被标记为 indirect，说明没在任何*_test.go里显式 import —— 很可能已被废弃，可删。
CI 中自动检测新增未使用依赖的最佳实践
在 CI 流程中加入静态检查，比靠人工 review 更可靠。推荐组合使用：
- 用
go list -u -m all检查是否有可升级但未更新的依赖（不是未使用，但属优化范畴）； - 用
go mod graph+awk统计出现频次，过滤出只被一个模块引用、且非标准库的冷门依赖，人工复核； - 集成
gofumpt -l或goimports -l配合 pre-commit，防止新代码引入未使用的 import； - 对
go.mod做 diff 检查：CI 构建前保存一份 cleango.mod，构建后运行go mod tidy，比较差异，若新增了 indirect 条目，触发告警而非直接合并。
真正难处理的是那些通过字符串拼接、plugin.Open 或 reflect.ImportPath 动态加载的依赖——它们永远无法被静态分析捕获，必须靠文档标注和团队约定约束。
