fiber 默认不支持 pprof，因其绕过 http.defaultservemux，而 pprof 仅向其注册；需用 fiber.wraphandler 包装 http.defaultservemux 并显式挂载 /debug/pprof/*path 路由，同时注意鉴权、端口绑定及 ?gc=1 采集时机。
直接在 Fiber 中用 net/http/pprof 无法生效，因为 Fiber 不基于 http.DefaultServeMux，必须手动挂载 handler；否则访问 /debug/pprof/ 会 404。
为什么 Fiber 默认不支持 pprof
Fiber 是一个独立的 HTTP 路由器，它完全绕过了标准库的 http.ServeMux 和 http.DefaultServeMux。而 net/http/pprof 的 init() 函数只向 http.DefaultServeMux 注册路由——这在 Fiber 里根本不会被使用。所以即使你写了 import _ "net/http/pprof"，/debug/pprof/heap 依然返回 404。
常见错误包括：
- 只导入包但没注册到 Fiber 的
app实例上 - 误以为
app.Use(pprof.Handler("heap"))可以直接用（实际不能，Fiber 的中间件签名和 pprof.Handler 不兼容） - 用
app.Get("/debug/pprof/*path", ...)但未正确透传 path 参数，导致子路径（如/debug/pprof/heap?gc=1）解析失败
如何在 Fiber 中正确挂载 pprof 路由
核心思路：把 net/http/pprof 的 handler 包装成 Fiber 中间件，显式处理 *path 并透传给标准 handler。推荐用 fiber.WrapHandler 包装 http.DefaultServeMux，再提前注册所有 pprof 路由到它上面。
实操步骤：
- 在
main()开头，调用pprof.Index、pprof.Profile等函数向http.DefaultServeMux注册（或直接import _ "net/http/pprof"） - 创建 Fiber 应用后，用
app.All("/debug/pprof/*path", fiber.WrapHandler(http.DefaultServeMux)) - 确保监听地址绑定到
0.0.0.0:6060而非localhost:6060，否则压测机无法访问 - 生产环境务必加鉴权，例如在
fiber.WrapHandler外层套一层中间件校验Authorizationheader 或内网 IP
示例代码片段：
import (
"net/http"
_ "net/http/pprof"
"github.com/gofiber/fiber/v2"
"github.com/gofiber/fiber/v2/middleware/adaptor"
)
func main() {
app := fiber.New()
app.All("/debug/pprof/*path", fiber.WrapHandler(http.DefaultServeMux))
app.Get("/api/hello", func(c *fiber.Ctx) error {
return c.SendString("ok")
})
app.Listen(":6060")
}
采集 heap profile 时必须加 ?gc=1
Fiber 服务并发高时，堆内存分配快、GC 滞后，/debug/pprof/heap 默认返回的是「当前驻留对象」(inuse_space)，但若没触发 GC，看到的往往是积压旧对象，不是真实瓶颈点。
正确做法：
- 先触发一次 GC：
curl "http://localhost:6060/debug/pprof/heap?gc=1"（Go 1.19+ 支持） - 稳定压测 30 秒后，再执行该请求，避免采样时 runtime 正忙于标记-清除导致数据中断
- 对比两次
?gc=1结果：如果inuse_space持续增长且runtime.GC()后不回落，才可能是泄漏 - 分析时用
go tool pprof -http=:8081 http://localhost:6060/debug/pprof/heap?gc=1，Web 界面顶部 dropdown 切换为alloc_space查累计分配热点
避免中间件干扰 goroutine 和 block 分析
Fiber 的日志、Recovery、CORS 等中间件常在每个请求中创建闭包、捕获上下文或持有 request body 引用，会导致 /debug/pprof/goroutine?debug=2 或 /debug/pprof/block 中出现大量匿名栈帧，掩盖真实问题（比如 DB 连接池耗尽、JSON 解析卡住）。
排查建议：
- 临时禁用非必要中间件（尤其是自定义中间件），再抓一次
goroutine?debug=2快照 - 重点看处于
running、syscall或长时间chan send状态的栈，而非runtime.gopark占比高的 - 用
go tool pprof加载后执行top -cum，过滤掉fiber.前缀函数，聚焦业务代码行号 - 若怀疑是锁竞争，改用
/debug/pprof/mutex?debug=1，查看contention字段是否异常高
最易被忽略的一点：pprof 数据从注册那一刻才开始采集，上线前漏配或注释掉挂载逻辑，等于放弃所有历史性能线索。别等 CPU 飙升了才想起来加——它得一直开着，只是控制访问权限。
