Go程序内存持续上涨且GC后不回落，八成是对象被“钉住”未释放，需通过两次heap快照diff定位泄漏点，并重点检查goroutine持有、map/sync.Map持久化、全局变量捕获等隐式引用。
Go 程序内存持续上涨、GC 后不回落，八成不是堆分配失控，而是对象被“钉住”没释放——真正要盯的不是 inuse_space 多少，而是谁在 hold 住那些本该被回收的内存。
怎么抓到真实的 heap profile（不是假采样）
Go 的 runtime/pprof 默认不自动抓堆快照，pprof.StartCPUProfile 对 heap 完全无效。线上服务必须显式触发，否则拿到的全是空或过时数据。
- 线上：启动时加
http.ListenAndServe("localhost:6060", nil)，然后用wget http://localhost:6060/debug/pprof/heap -O heap1.pb.gz；注意别加?gc=1，它强制 GC 后采样，会把真实存活对象“刷掉”，掩盖泄漏 - 本地复现：在疑似泄漏点前后调用
pprof.WriteHeapProfile(f)，文件名必须带.heap或.pb.gz后缀，否则go tool pprof无法识别 - 验证是否采到真实数据：用
go tool pprof -http=:8080 heap1.pb.gz打开后，右上角 View → 切到Allocation space，如果高频小对象分配量远高于inuse_space，说明有大量对象被创建又快速释放——这不是泄漏；但如果inuse_space持续爬升，且Allocation space增速平缓，才是典型泄漏信号
为什么 top 看到大结构体，list 却找不到分配点
top 按当前存活对象总大小排序，list 显示的是函数内所有分配（含已 GC 的），两者统计口径不同。常见现象是 top 里看到 *UserConfig 占 150MB，但 list UserConfig 几乎为空——这说明你代码里没直接 &UserConfig{}，而是通过第三方库间接创建，比如 json.Unmarshal 解析进全局 map[string]*UserConfig，或 sync.Map.LoadOrStore 持久化了指针。
- 重点检查：
map/sync.Map的 key 是否重复写入、slice是否用b[:n]截取后赋给全局变量（底层底层数组仍被引用） - 用
web视图看调用链：如果大量runtime.mallocgc直接连到main.main或某个初始化函数，说明主 goroutine 在启动期就建了一堆对象并长期持有，比如未关闭的http.Client.Transport、未清理的time.Ticker - 执行
pprof -symbolize=none可绕过符号解析失败问题，避免因缺少 debug info 导致调用栈显示为???
goroutine 数暴涨但 heap 不涨？那是“钉子户”在作祟
每个 goroutine 栈初始仅 2KB，本身不占多少内存。但它只要活着，就能 hold 住任意大的对象——比如一个闭包捕获了含 []byte 的 struct，或一个后台 goroutine 持有数据库连接池的引用。这时 /debug/pprof/heap 看不到泄漏源头，因为内存是被活跃 goroutine “钉住”的。
立即学习“go语言免费学习笔记（深入）”；
- 先抓
/debug/pprof/goroutine?debug=2（必须带?debug=2，否则只显示统计摘要） - 重点关注：大量 goroutine 停在
select无 default 分支、time.After循环创建未回收 timer、http.Client调用后未关闭 response.Body - 对比泄漏前后 goroutine 堆栈：用
runtime/pprof.Lookup("goroutine").WriteTo(os.Stdout, 2)手动 dump，diff 文本即可定位新增的固定模式栈帧 - Redis 连接池泄漏典型表现：
redis.NewClient在每次请求中调用而非单例复用，/goroutine?debug=2里会出现数百个github.com/go-redis/redis/v8.(*Client).Get堆栈，且每个都关联独立 client 实例
两次 heap 快照 diff 才能暴露“隐形泄漏”
单次 heap 快照常显示“一切正常”，因为泄漏对象占比小、被业务大结构体淹没。真正的泄漏是缓慢累积的，必须靠时间维度放大差异。
- 间隔 5–10 分钟抓两个快照：
wget http://localhost:6060/debug/pprof/heap -O heap1.pb.gz，等一段时间再抓heap2.pb.gz - 用
go tool pprof -base heap1.pb.gz heap2.pb.gz启动 web，它会高亮增长最猛的类型和调用路径 - 特别留意
sync.Map.Store、runtime.mapassign、bytes.makeSlice下游的类型——这些是 map/slice/json 底层分配入口，泄漏往往藏在它们背后 - 如果 diff 结果里
inuse_space增长集中在某个第三方包（如golang.org/x/net/http2），优先查文档看是否需手动调用Close或配置MaxConcurrentStreams
最易被忽略的一点：泄漏可能不在你写的业务逻辑里，而在初始化阶段——比如全局 sync.Pool 的 New 函数返回了带大字段的 struct，或 http.ServeMux 注册 handler 时闭包捕获了整个 service 实例。这类问题不会在压测时立刻爆发，但上线几天后内存曲线就会走出那条“优雅的 30 度斜线”。
