go mod tidy 会删除既未被任何 .go 文件 import 语句引用、也未被其他依赖传递引入的模块；包括注释掉的 import、不匹配构建标签的依赖、以及无副作用的空白导入（如 import _ "github.com/lib/pq"）所对应的模块。
go mod tidy 会删掉哪些依赖
go mod tidy 的核心行为是「按需收敛」：它只保留 go.mod 中当前模块直接 import 的包，以及这些包的间接依赖中**被实际构建路径引用到的部分**。它不会删除所有未显式 import 的包——比如你 import "github.com/sirupsen/logrus"，但代码里没调用任何 logrus 函数，go mod tidy 依然会保留它，因为 import 语句存在。
真正会被删掉的是：既没出现在任何 .go 文件的 import 列表中，又没被其他依赖 transitively 引入的模块。常见误删场景包括：
- 注释掉的 import（如
// import "net/http"）不计入，对应模块可能被删 - 仅在 build tag 条件下使用的依赖（如
//go:build integration），若当前GOOS/GOARCH或 tags 未匹配，go mod tidy可能忽略其 import 而误删 - 通过
_导入但无运行时副作用的包（如import _ "github.com/lib/pq"），只要没被其他包依赖，也会被删
如何安全识别和移除真正未使用的依赖
仅靠 go mod tidy 不够，得结合静态分析。推荐用 go list + go mod graph 定位「孤儿模块」：
先生成当前模块所有依赖关系图：go mod graph | awk '{print $1}' | sort -u > all-deps.txt
立即学习“go语言免费学习笔记（深入）”；
再列出项目中所有显式 import 的模块（排除标准库和本地 replace）：grep -r 'import "\(.*\)"' --include="*.go" . | sed -E 's/.*"([^"]+)".*/\1/' | grep -v '^$' | sort -u > used-deps.txt
最后取差集：comm -13
结果里的模块大概率可删，但需注意：
- 某些包仅通过
init()注册（如数据库驱动），必须保留在 import 中，即使没直接调用 - 如果用了
replace或exclude，需手动检查是否影响依赖图准确性 -
go list -deps ./...比go mod graph更准，但输出含版本号，解析稍麻烦
go mod vendor 后清理 vendor 目录中的冗余包
go mod vendor 默认把 go.mod 里所有依赖（含间接依赖）全拷进 vendor/，但其中不少可能根本没被编译进最终二进制。要精简 vendor，得先确保 go mod tidy 已清理干净，再执行：
go mod vendor -v 2>&1 | grep 'skipping'
这行命令会输出被跳过的包——它们是 vendor 认为「当前构建不需要」的模块。不过这个「跳过」基于当前构建环境（GOOS/GOARCH/tags），不是绝对安全的删除依据。
更稳妥的做法是：在 clean 环境下运行完整构建链（包括 test、cross-build、CI 所有 target），再对比 vendor/ 和 go list -f '{{.Dir}}' ./... 输出的源码路径，找出 vendor 中没被任何 .go 文件 import 的目录。手动删前建议用 git checkout vendor/xxx 备份。
CI 中自动化依赖健康检查
在 CI 流程里加一步「依赖漂移检测」能避免遗忘清理。例如在 GitHub Actions 中插入：
bash
- name: Check unused dependencies
run: |
go mod tidy -v 2>&1 | grep -q "removing" && echo "⚠️ go mod tidy removed deps — review needed" && exit 1 || echo "✅ No unused deps found"
或者用第三方工具如 go-mod-outdated 或 godeps 做增量扫描。但要注意：
- CI 环境的
GOFLAGS（如-mod=readonly）可能让go mod tidy报错而非静默跳过 - 多 module 项目（含 replace 到本地路径）容易误报，建议限定检查范围：
go mod tidy -v ./cmd/... ./pkg/... - 别把「未使用」和「过时」混淆：
go list -u -m all查的是版本更新，不是引用状态
依赖清理最麻烦的从来不是命令怎么敲，而是判断某个包到底算不算“真没用”——尤其当它藏在 init 函数、插件注册或测试 setup 里时，静态分析大概率漏掉。动手删之前，最好 grep 全局搜包名 + _ + init + Register，再扫一眼 test 文件。
