fiber 默认不支持 pprof，因其基于 fasthttp 而非 net/http，而 net/http/pprof 仅向 http.defaultservemux 注册，需手动用 fiber.wraphandler 桥接并确保注册顺序正确。
pprof 在 Fiber 中默认完全不可用，必须手动挂载且绕过 fasthttp 的路由机制，否则所有 /debug/pprof/* 请求都会 404 或被静默丢弃。
为什么 Fiber 默认不支持 pprof
Fiber 基于 fasthttp，不兼容标准库的 net/http 接口。而 net/http/pprof 的 init() 函数只向 http.DefaultServeMux 注册 handler，对 Fiber 的 app 实例完全无感知。
常见错误包括：
- 只写了
import _ "net/http/pprof"，但没做任何路由桥接 → 访问/debug/pprof/直接 404 - 试图用
app.Get("/debug/pprof/*", ...)包裹 pprof handler →fasthttp不支持http.Handler接口，会 panic 或空响应 - 用
fiber.WrapHandler(http.DefaultServeMux)→ 只能转发到DefaultServeMux已注册的路径，但 Fiber 启动时DefaultServeMux是空的（除非你提前注册）
正确挂载方式：用 fiber.WrapHandler + 显式注册
必须分两步：先让 net/http/pprof 注册进 http.DefaultServeMux，再用 fiber.WrapHandler 把它桥接到 Fiber 路由。
实操代码片段：
<pre class="brush:php;toolbar:false;">import (
"net/http"
_ "net/http/pprof" // 触发 init()，向 http.DefaultServeMux 注册
"github.com/gofiber/fiber/v2"
)
func main() {
app := fiber.New()
// 关键：必须在 app.Listen 前，用 WrapHandler 桥接 DefaultServeMux
app.All("/debug/pprof/*", fiber.WrapHandler(http.DefaultServeMux))
app.Get("/", func(c *fiber.Ctx) error {
return c.SendString("ok")
})
app.Listen(":3000")
}
注意点：
- 路径必须用
All()，因为 pprof 内部有多个子路径（如 <code>/debug/pprof/heap、/debug/pprof/profile），且部分使用POST方法 - 不能写成
app.Get("/debug/pprof/*", ...)，否则profile等 POST 请求失败 - 确保
http.DefaultServeMux注册发生在fiber.WrapHandler调用之前 —— 下划线导入已足够，无需额外调用
采集 heap profile 时务必加 ?gc=1
Fiber 高并发下对象分配快、GC 滞后，不强制 GC 就抓 /debug/pprof/heap，看到的几乎全是积压旧对象，无法反映真实内存压力。
正确做法：
- 压测稳定 60 秒后，执行：
curl "http://localhost:3000/debug/pprof/heap?gc=1" - 若需对比增长趋势，连续请求时加
&next=1参数：curl "http://localhost:3000/debug/pprof/heap?gc=1&next=1" - 避免和 CPU profile 同时采集 ——
fasthttp的高吞吐会让 pprof 的采样信号被冲刷，数据可能中断或为空
中间件干扰问题比 Gin 更隐蔽
Fiber 的中间件（尤其是 logger、recover、requestid）常在闭包中捕获整个 *fiber.Ctx，导致 pprof 的 top 或火焰图里大量出现 github.com/gofiber/fiber/v2.(*Ctx).Next 或匿名函数，掩盖真正分配源（比如 JSON 解析、DB Scan）。
排查建议：
- 临时关闭非必要中间件，仅保留 pprof 路由，再抓一次 heap profile 对比
- 用
go tool pprof -http=:8081 heap.pprof打开后，在顶部 dropdown 切换为alloc_space，再用Focus输入json.Unmarshal或database/sql.(*Rows).Scan看是否真在这些位置分配 - 如果
top里*fiber.Ctx占比异常高，说明中间件持有 ctx 时间过长，需检查是否误用了c.Locals存大对象或未及时c.Reset()
最易被忽略的是：Fiber 的 WrapHandler 桥接后，pprof 的 /debug/pprof/goroutine?debug=2 返回的堆栈里，顶层永远是 fasthttp 的调度函数，不是业务 handler 名 —— 这不是 bug，是 fasthttp 的协程复用模型决定的；要看真实业务调用链，得结合 block 或 mutex profile 交叉验证。
