fiber框架本身不导致内存泄漏，问题源于用户代码：闭包捕获大对象、context.value未清理、sync.map缓存不删除、time.ticker未stop；抓heap profile须避三坑——禁用?gc=1、文件名带.heap/.pb.gz后缀、采样间隔≥30秒且避开启动期。
Go 语言用 Fiber 框架本身不会导致内存泄漏，真正出问题的是你写在 Fiber handler、中间件或全局结构里的代码——比如闭包捕获大对象、context.Value 塞了没清理的指针、sync.Map 存了永不删除的缓存项，或者启了 time.Ticker 却没 Stop()。
抓 heap profile 必须避开的三个硬坑
线上看到内存缓慢上涨，第一反应不是改代码，而是先确认 profile 数据是否可信。90% 的误判源于采样方式错误：
- 绝对不要加
?gc=1：它强制 GC 后采样，会把本该长期存活的泄漏对象“刷掉”，profile 里只剩临时垃圾 - 文件名必须带
.heap或.pb.gz后缀，例如before.heap，否则go tool pprof报unrecognized profile format - 别在刚启动或
MemStats.NextGC接近HeapAlloc时采样——这时 GC 正疯狂 sweep，快照全是待回收噪声
稳当做法：服务稳定运行 5 分钟以上 → wget http://localhost:6060/debug/pprof/heap -O before.heap → 等满 30 秒 → 再抓一次 after.heap。
用 pprof 差分定位 Fiber 中的泄漏源
执行 go tool pprof -http=:8080 -base before.heap after.heap，浏览器打开后关键三步：
- 右上角 SAMPLE 切到
inuse_space（不是alloc_objects） - 点 View → Difference（不是 Top 或 Flame Graph）——只有差分才能看到净增长
- 搜索框输入
Focus *UserConfig或你怀疑的类型，再点 Call graph
重点盯调用链里夹着这些关键词的路径：(*fiber.Ctx).Next（中间件未退出）、context.WithValue（值塞进去了没清）、json.Unmarshal（直接解到全局 map[string]*T 且 key 不删）、time.AfterFunc（Fiber handler 里启了定时器但没绑定生命周期）。
Fiber 特有的泄漏高危点
Fiber 的轻量和链式设计容易掩盖引用生命周期问题：
-
ctx.Locals("key", bigStruct)后没在 handler 结束前清理，bigStruct会被整个fiber.Ctx实例钉住，直到下次复用或 GC - 自定义中间件里用
go func() { ... }()启 goroutine，但没传入ctx.Context或没监听ctx.Context.Done()，导致协程永远卡在chan receive - 静态文件服务（
app.Static）配错路径，触发大量os.Open失败但没 close，文件句柄 + 底层 buffer 双泄漏 - 全局
fiber.App实例上挂了sync.Map缓存，但没配过期逻辑，LoadOrStore后 key 永远不删，[]byte越积越多
查 goroutine 是否泄漏，别只看 /debug/pprof/goroutine 默认页——必须用 ?debug=2，重点找阻塞时长超 300s 的堆栈，尤其是卡在 net.Conn.Read、select 或已关闭 channel 的 send 上。
修复后验证不能只看内存数字
改完代码压测，别只盯着 HeapInuse 是否回落。真修复必须同时满足：
-
runtime.NumGoroutine()在请求结束后回落到基线值（比如空闲态是 42，处理完还是 42） -
pprof /goroutineleak?debug=1（Go 1.24+）返回为空，或goleak.VerifyNone测试通过 - 连续 3 次重启后，在相同流量下
HeapInuse增长斜率归零，且GC后不反弹
最容易被忽略的是：Fiber 的 Ctx 复用机制会让泄漏对象“跨请求存活”。哪怕你每个 handler 都 new 一个 struct，只要它被闭包捕获并逃逸到堆，就可能被下一个请求的 Ctx 实例继续持有——所以必须从引用源头切断，而不是靠“每次新建”来赌运气。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
