是，go mod tidy 会自动删除未使用的依赖，但仅限于 go.mod 中已声明、且当前模块源码中完全无 import 的包；它不处理间接依赖中仍被引用的包、本地缓存或 vendor 目录残留。
go mod tidy 会自动删掉未使用的依赖吗
会，但仅限于 go.mod 中已声明、但当前模块源码里完全没 import 的包。它不会碰间接依赖（indirect）中仍被其他依赖链引用的包，也不会清理本地缓存或 vendor 目录里的残留。
常见误判场景：某个包只在 //go:embed、//go:generate 或测试文件（*_test.go）中使用，但主代码没 import —— 默认情况下 go mod tidy 会把它删掉，除非你显式保留测试依赖。
- 运行前先备份：
git add go.mod go.sum && git commit -m "before tidy" - 确保所有构建变体都覆盖到：用
GOOS=linux GOARCH=amd64 go mod tidy等组合跑一遍，避免因构建约束漏删/误删 - 如果项目含
main包以外的多个 module（如 cmd/xxx），需逐个目录执行go mod tidy
为什么 go mod tidy 没删掉某个明显不用的包
最常见原因是该包仍被某个 indirect 依赖间接引用，或者被 replace / exclude 规则“钉住”了。另一个隐蔽原因是 Go 工具链把 test 依赖和主依赖分开处理，默认不扫描 _test.go 文件。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 查依赖路径：
go mod graph | grep 'unwanted-package'，看谁在拉它 - 强制排除（慎用）：
go mod edit -droprequire github.com/some/unused，再跑go mod tidy - 若包仅用于测试，加
//go:build test并运行go mod tidy -compat=1.21（Go 1.21+ 支持测试专属依赖管理）
删除后如何验证没破坏构建和运行
删依赖不是改完 go.mod 就结束，得验证真实使用链是否断裂。尤其要注意 CGO、插件、反射加载、嵌入文件等隐式依赖。
- 全量构建：
go build -o /dev/null ./...（注意是./...，不是.） - 运行所有测试：
go test -race ./...，加上-tags=netgo等常用构建标签 - 检查二进制符号表（对怀疑被反射调用的包）：
go tool nm ./mybinary | grep 'SomeUnusedType' - CI 中建议加一步：
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./... | sort -u | wc -l对比删前后数量
vendor 目录里的无用包怎么同步清理
go mod vendor 不会自动删 vendor 下的旧包，它只按当前 go.mod 同步。所以必须先 go mod tidy 清理依赖图，再重生成 vendor。
- 两步必须连做：
go mod tidy && go mod vendor，中间不能手动改vendor/ - 确认 vendor 完整性：
go mod verify应返回 success，且git status vendor/只显示删减，无新增乱码文件 - 若用 Makefile 或 CI 脚本，避免写成
go mod vendor && go mod tidy—— 顺序反了会导致 vendor 里留着脏包
真正麻烦的是那些通过字符串拼接 import 路径、或用 plugin.Open() 动态加载的包，它们不会出现在 AST 分析里，go mod tidy 根本看不见。这种得靠人工核对文档、运行时日志或 panic 堆栈反推。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
