Fiber 中必须手动挂载 pprof 路由，否则 /debug/pprof/ 返回 404；需通过 app.Get("/debug/pprof/*pprof", ...) 桥接 http.DefaultServeMux；采集 heap profile 必须加 ?gc=1；goroutine profile 易受中间件闭包污染；内存问题需交叉分析 heap 和 allocs。
Fiber 中必须手动挂载 pprof 路由，否则 /debug/pprof/ 返回 404
Fiber 默认不注册任何 pprof handler，net/http/pprof 包的路由不会自动生效。即使你 import _ "net/http/pprof"，也仅是初始化了 http.DefaultServeMux，而 Fiber 使用自己的 fiber.App 实例处理请求，两者完全隔离。
常见错误：开发者以为加了 import 就能直接访问 /debug/pprof/heap，结果返回 404 —— 这是因为 Fiber 根本没把请求转发给 DefaultServeMux。
- 正确做法：用
app.Get("/debug/pprof/*pprof", func(c *fiber.Ctx) error { return c.SendStatus(404) })占位后，再通过http.StripPrefix+http.Handler桥接 - 推荐写法（兼容 Fiber v2.50+）：
import _ "net/http/pprof" // 在 app 初始化后、启动前插入 app.Get("/debug/pprof/*pprof", func(c *fiber.Ctx) error { c.Set("Content-Type", "text/plain; charset=utf-8") http.DefaultServeMux.ServeHTTP(c.Response().Writer, c.Request().Request) return nil }) - 务必确保该路由在所有中间件（如 JWT、CORS）之后注册，否则鉴权中间件会拦截
/debug/pprof/请求 - 监听地址不能只绑
127.0.0.1:3000；压测机需访问时，得用0.0.0.0:3000
采集 heap profile 前必须加 ?gc=1，否则数据严重失真
Fiber 高并发场景下对象分配快、GC 滞后，/debug/pprof/heap 默认返回的是「当前存活对象」（inuse_space），但若未强制触发 GC，采样到的很可能是上一轮未回收的积压对象，而非真实瓶颈点。
例如：一个 handler 每次请求都 new 一个 map[string]interface{}，但 GC 还没来得及运行，profile 显示的却是旧的、已无业务关联的结构体实例。
- 正确采集命令：
curl "http://localhost:3000/debug/pprof/heap?gc=1"（Go 1.19+ 支持，Fiber 项目通常用 Go 1.21+） - 不要依赖
runtime.GC()手动调用后再 curl —— 因为 GC 是异步的，调用后立即 fetch 可能仍为空或中断 - 更稳妥流程：先稳定压测 30 秒 → 发送
?gc=1请求 → 等待 1–2 秒 → 再curl -o heap.pprof ... - 如果想看累计分配量（查高频小对象），改用
/debug/pprof/allocs，它本身就会触发一次 GC
Fiber 中 goroutine profile 容易被中间件闭包污染
Fiber 的中间件（比如日志、Recovery、JWT）常在闭包中捕获 c *fiber.Ctx 或 request body，导致 pprof 的 goroutine profile 出现大量 http.HandlerFunc、func·001 等匿名函数占位，真正泄漏的业务协程反而被掩盖。
典型现象：go tool pprof http://localhost:3000/debug/pprof/goroutine 中 top 显示 80% 是 runtime.gopark + 中间件闭包，而不是你的 DB 查询或 JSON 解析逻辑。
- 临时规避：启动前加环境变量
GODEBUG=schedtrace=1000，观察调度器是否卡在某个中间件 goroutine 上 - 精准定位：用
go tool pprof -http=:8081 http://localhost:3000/debug/pprof/goroutine?debug=2查看完整堆栈，过滤掉fiber/middleware/路径 - 长期建议：对关键中间件做轻量化改造，避免在闭包中持有大对象（如整个
c.Body()字节切片） - 注意 Fiber 的
Ctx.Locals如果存了 map/slice，且生命周期跨多个 handler，也会出现在 goroutine profile 的引用链里
区分内存膨胀和 GC 瓶颈，得同时看 heap 和 allocs profile
单看 inuse_space 高 ≠ 内存泄漏；单看 top 里 runtime.gcBgMarkWorker 占比高 ≠ GC 配置不当。Fiber 应用的内存问题必须交叉验证。
例如：某接口 QPS 上升后 RSS 持续涨，但 go tool pprof -inuse_objects 显示 github.com/gofiber/fiber/v2.(*Ctx) 实例数稳定，而 go tool pprof -alloc_space 显示 encoding/json.(*decodeState).object 分配量暴增 —— 这说明不是泄漏，是 JSON 解析太频繁，GC 来不及清理。
- 泄漏信号：
go tool pprof -inuse_objects中某个业务 struct 实例数随时间线性增长，且调用栈固定指向某 handler - GC 瓶颈信号：
go tool pprof -http=:8081 http://localhost:3000/debug/pprof/profile（CPU profile）里runtime.gcDrainN或runtime.scanobject占比 >15% - 别信
GODEBUG=gctrace=1的日志频率 —— 它只告诉你 GC 多久跑一次，不反映 mark/scan 阶段耗时 - 生产环境采样要控制频率：
?seconds=30限制采集时长，避免 pprof 自身吃光 CPU
