go项目瘦身关键在阻断传递性依赖：用go mod graph和gomodtree定位幽灵引入，go mod why排查未使用依赖，工具类移至tools.go，私有模块设goprivate，替换前用go tool nm验证实际符号占用。
Go 项目体积大，八成不是因为某个包本身臃肿，而是依赖树里塞了大量没被调用的间接依赖——go mod tidy删不掉它们，go list -m all却能一眼揪出。
用 go mod graph 和 gomodtree 看清谁在偷偷拉依赖
扁平输出看不清层级，就别硬读 go mod graph；树形结构才适合定位“幽灵引入源”。
-
go mod graph适合管道筛选：比如go mod graph | grep logrus快速查某个包被谁拉进来 -
gomodtree要装最新版：go install github.com/loic-lopez/gomodtree@latest，旧版本不支持 Go 1.22+ 的模块解析逻辑 - 注意重复出现的子依赖（如多个路径都引了
golang.org/x/sys@v0.15.0），这往往是版本未对齐或 replace 残留的信号
用 go mod why 定位“不该存在的依赖”
看到一个包出现在 go list -m all 里，但代码里根本没 import 它？大概率是测试、工具或弃用模块带进来的。
- 运行
go mod why github.com/sirupsen/logrus，如果输出里含test或tools.go，说明它只在测试或 dev 工具链中被引用 - 若输出显示来自已删除的模块（比如
github.com/old-org/legacy-pkg），检查go.mod是否还残留replace或exclude - 某些框架（如
ent）会在生成代码时写死依赖，此时要确认entc是否还在tools.go里，否则它会持续污染主依赖树
替换“全家桶”前先验证导出符号是否真被用了
别一看到 gin 就换 net/http，也别看到 gorm 就切 sqlc——得先确认你到底用了它几成能力。
- 用
go tool nm ./main | grep "github.com/gin-gonic/gin"查二进制里实际保留的符号，如果只有gin.New和(*Engine).GET，那其他中间件、渲染器、日志模块全没被打包进去 - 标准库替代的前提是：你没用任何第三方扩展点（比如 gin 的
Context.Set、c.MustGet），否则 runtime panic - ORM 替换最易踩坑：如果用了
gorm.Model(&u).Select("name").Updates(...)这类链式调用，sqlc 无法覆盖，强行替换会导致编译失败或逻辑错位
瘦身不是删依赖，是阻断传递性引入
真正有效的依赖控制，发生在模块定义层，而不是等 go mod tidy 善后。
- 把工具类依赖（
mockgen、swag、ginkgo）全部移到tools.go文件，并加//go:build tools构建约束，它们就不会进主依赖树 - 私有模块必须设
GOPRIVATE=git.internal.company/*，否则 proxy 会 fallback 到 public index，导致版本解析异常、间接依赖失控 - 慎用
replace：它会让go mod graph显示错误路径，且可能掩盖上游已修复的安全问题；优先用require+version锁定，再配合go mod verify校验
依赖树瘦身最难的点不在命令怎么敲，而在于判断“这个包我到底需不需要它全部能力”——很多团队删完 echo 改用 net/http 后，发现路由分组、CORS 中间件、绑定校验全得自己补，最后体积没减多少，维护成本反而翻倍。动手前，先跑一遍 go tool nm 看真实符号占用，比凭经验删更可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
