go mod tidy 仅删除代码中未 import 且无间接引用的模块，无法识别反射、配置或条件编译引入的依赖；冗余依赖通过符号膨胀、init 副作用和长依赖链推高内存，需结合二进制大小、pprof 和运行时指标验证清理效果。
go mod tidy 不能删掉反射、配置或测试引入的依赖
它只删代码里没 import 且没被其他模块间接引用的模块。像 import _ "github.com/lib/pq" 这种空白导入，如果没别的包依赖 github.com/lib/pq，且它没注册 init() 副作用，go mod tidy 就会把它干掉；但若你通过 reflect.Value.Call 或 JSON 配置动态加载某个驱动，tidy 完全看不见——这类依赖必须人工核对。
- 检查方式：运行
go mod why -m github.com/some/unused，返回main module does not need module才算安全可删 - 测试专用模块（如
_test.go里用的github.com/stretchr/testify）默认会被 tidy 处理，但得确认go test ./仍能过 - 条件编译（
//go:build integration）下的 import，若当前构建未启用该 tag，tidy 会忽略对应路径，可能误删
冗余依赖如何实际抬高内存占用
不是所有冗余依赖都直接吃堆内存，但它们会通过三种方式推高整体开销：
- 链接期符号膨胀：多个版本的同一库（如
golang.org/x/netv0.17.0 和 v0.22.0）共存时，链接器无法去重，导致二进制体积增加 15%–25%，加载后 RSS 上升 - init() 函数副作用：某些模块在
init()里注册全局 handler、启动 goroutine 或预分配缓存（比如github.com/gorilla/sessions），哪怕没显式 import，只要被 tidy 保留就照常执行 - 间接依赖链过长：一个被保留的冗余模块可能拉入整套工具链（如旧版
github.com/spf13/cobra带着github.com/inconshreveable/mousetrap），而后者又隐式启动 goroutine，每个约 4.5 KB 栈内存
验证冗余依赖是否真影响内存的关键动作
别只盯着 go.mod 行数变化，得看 runtime 表现：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 跑两次
go build -ldflags="-s -w" -o app main.go，对比二进制大小——下降明显才说明链接层冗余被清理 - 启动程序后访问
/debug/pprof/heap，用go tool pprof查看 top 函数是否还含已删模块的包路径（如vendor/github.com/old/log） - 执行
go list -m all | wc -l和go mod graph | wc -l，前者减幅 >10%、后者边数下降才代表依赖图真正精简 - 特别注意
go mod tidy -v输出里带removing unused的行——如果某模块反复出现 “adding” 又 “removing”，大概率是replace冲突或构建标签不一致
处理完依赖后必须检查的三个内存敏感点
清理只是第一步，很多问题藏在运行时行为里：
- 查
runtime.ReadMemStats().HeapAlloc是否在空闲期稳定回落——若基线持续抬高，可能是被删模块里的全局 map 或 sync.Pool 被替换成新版本但没适配 reset 逻辑 - 确认所有
sync.Pool的New函数返回的是指针（如&bytes.Buffer{}），不是值类型（bytes.Buffer{}），否则 Get 后 panic - 检查 HTTP handler 中是否还有裸
go f()启动 goroutine，尤其那些依赖刚删模块的对象（比如旧版 logger 实例），容易因 panic 导致 goroutine 泄漏
真实场景中，冗余依赖引发的内存问题往往不是“多占几 MB”，而是让 GC mark 阶段扫描更多栈帧、让链接器打包更多符号、让 init() 无意中拉起后台 goroutine——这些都得靠运行时观测，而不是仅靠 go mod tidy 一键解决。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
