Fiber高性能依赖规避fasthttp零拷贝陷阱：ctx.BodyBytes()替代ctx.Body()、c.FormValue()替代手动解析、c.JSON()替代json.Unmarshal、用ParamsInt/QueryInt替代strconv.Atoi，禁用fiber.Logger()等I/O中间件。
直接上结论：Fiber 本身已默认高性能，但多数人一加日志、一读请求体、一传参数就退化成 net/http 水平；关键不在“用没用Fiber”，而在是否绕开了 fasthttp 的零拷贝陷阱。
ctx.Body() 是高并发下的典型内存雷区
ctx.Body() 每次调用都会分配新内存并拷贝整个请求体，QPS 上万时 GC 压力陡增；而 ctx.BodyBytes() 直接返回底层 []byte slice，零分配、零拷贝。
- 仅当你要修改内容时才需拷贝：
bytes.Copy或append([]byte{}, body) - POST 表单或 multipart 场景下，
c.FormValue("key")比c.Body()+ 手动解析快得多，且线程安全 - 别自己写
json.Unmarshal(c.Body(), &v)，直接用c.JSON(200, data)—— Fiber 内部用了预分配 buffer 和unsafe转换
路由参数和查询参数别碰 strconv.Atoi
Fiber 提供了带缓存的类型转换方法，绕过标准库 panic 风险和重复解析开销。
- 用
c.ParamsInt("id")替代strconv.Atoi(c.Params("id"))，失败时返回0和error，不 panic - 用
c.QueryInt("page")替代strconv.Atoi(c.Query("page")) - 路径中带可选参数（如
/:name/:age/:gender?）时，c.Params("gender")可能为空字符串，别直接转int
fiber.Logger() 是上线前必须关掉的 I/O 中间件
开发环境留着 app.Use(fiber.Logger()) 没问题；上线前必须删掉或换成采样式日志（如只记录 status ≥ 400 的请求）。
-
fiber.New(fiber.Config{DisableStartupMessage: true})只禁掉那一行⇨ http server started，对压测 QPS 几乎无影响 - 真正拖垮 QPS 的是每请求打一行的 I/O 中间件
- 自定义中间件里别用
fmt.Println或log.Printf，改用结构化日志库（如zerolog）并绑定c.Locals中的traceID - 如果用了
fiber.Recover()，注意它默认会打印 panic 堆栈到 stdout —— 生产环境应重定向或关闭
Prefork 不是银弹，开错反而更慢
Prefork 在 Linux 上 fork 多进程，但进程间无法共享内存，每个子进程都得重新初始化 DB 连接池、缓存等资源。
- 仅当压测发现单进程 CPU 使用率持续 ≥95%、且机器有 ≥6 物理核、SSD IO 充足时，才考虑开启
Prefork: true - 开启后
app.Shutdown()必须配合os.Interrupt信号处理，否则子进程可能残留 - 绝大多数场景下，单进程 + 正确使用
ctx.BodyBytes()、c.JSON()、c.FormValue()就已足够应对数万 QPS
最容易被忽略的点是：所有「看似无害」的字符串拼接、fmt.Sprintf、strconv 转换、手动 JSON 解析，都在悄悄触发内存分配——它们在压测时不会报错，但会让 QPS 断崖式下跌。
