go mod tidy 不能完全解决包数量问题，因其仅清理未被 import 的直接依赖，而对间接依赖（indirect）极为宽容，即使代码中完全未使用，只要被其他包引入就会保留在 go.mod 中。
为什么 go mod tidy 不能完全解决包数量问题
go mod tidy 会清理未被 import 的直接依赖，但对间接依赖（indirect）很宽容——只要某个依赖被其他包引入，哪怕你代码里一行都没用它，它就会留在 go.mod 里。久而久之，go list -m all | wc -l 可能轻松破百，其中大量是 transitive 依赖的旧版本或调试工具链残留。
-
indirect标记不等于“无用”，只是当前模块没直接 import 它 - 某些包（如
golang.org/x/sys）被多个标准库组件反复拉入，版本不统一时会并存多个伪版本 -
go get带分支或 commit hash 会生成不可复现的伪版本，后续go mod tidy不会自动降级或合并
建议每轮功能迭代后手动检查：go list -m all | grep -v '^\(std\|golang.org/x\|runtime\)' | sort，重点关注非官方、非标准库的长尾依赖。
如何识别并剔除“幽灵依赖”
所谓幽灵依赖，是指go.mod 里有记录、但实际代码中从未 import 的包——常见于早期 go get 试用后忘记清理，或重构时删了 import 却没运行 go mod tidy。
- 运行
go mod graph，搜索只出不进的模块（即没有其他模块依赖它） - 对疑似包执行
go list -f '{{.Imports}}' github.com/some/pkg，确认它是否真被任何包 import - 若确认无引用，直接删掉
go.mod中对应require行，再跑一次go mod tidy
特别注意：有些包（如 github.com/go-sql-driver/mysql）可能仅在 _ 导入（import _ "github.com/go-sql-driver/mysql"），这种不会出现在 AST 扫描中，需人工核对。
避免因开发便利引入冗余依赖
本地开发时容易为“先跑起来再说”加一堆工具类依赖：mock 框架、benchmark 工具、debug pprof UI、临时 CLI 解析器……这些不该进入生产构建。- 把开发专用依赖放在
tools.go文件中，并用//go:build tools约束构建标签 - 在该文件中 import 工具包（如
golang.org/x/tools/cmd/stringer），它们不会污染主模块的go.mod - 运行
go mod tidy -compat=1.18（或你最低支持版本）可强制剔除仅用于高版本语法的依赖
别把 vendor/ 当保险柜——go mod vendor 会原样复制所有 go list -m all 结果，包括那些幽灵依赖。除非 CI 明确要求锁定 vendor，否则现代 Go 项目通常不提交 vendor 目录。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
替换比引入更有效：用标准库或轻量替代品
第三方包数量膨胀，往往源于重复造轮子。比如：- 用
net/http+io.ReadAll替代github.com/parnurzeal/gorequest - 用
encoding/json的json.RawMessage和自定义UnmarshalJSON替代全量 JSON Schema 库 - 用
strings.TrimSpace+strconv.ParseInt替代整套 CLI 参数解析器（除非真需要子命令、补全等）
真正难处理的是“深度嵌套依赖”：你只 import 一个 ORM，结果带进 30+ 个 indirect 包。这时与其逐个 replace，不如评估是否值得换更薄的替代方案——比如从 gorm.io/gorm 切到 entgo.io/ent，后者依赖树明显更收敛。
控制数量不是为了数字好看，而是降低 go.sum 冲突概率、缩短 CI 下载时间、减少安全扫描误报。最常被忽略的一点：go mod verify 失败往往不是因为某个包被篡改，而是因为某个早已不用的 indirect 包的校验和在不同 Go 版本间不一致——它安静躺在那里，直到某次升级才突然爆发。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
