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/net v0.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 冲突或构建标签不一致

处理完依赖后必须检查的三个内存敏感点

清理只是第一步，很多问题藏在运行时行为里：

立即学习“go语言免费学习笔记（深入）”；

• 查 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 一键解决。