必须关闭DisableStartupMessage和EnablePrintRoutes以避免QPS超2万时抖动丢包；路径参数用c.ParamsInt、请求体用c.BodyBytes、JSON解析避reflect；handler内显式SetDeadline；Prefork与连接池需按场景调优。
上线前不关 DisableStartupMessage 和 EnablePrintRoutes，QPS 过 2 万就容易抖动丢包——这不是框架不行，是默认日志和路由树打印吃掉了 CPU 和初始化时间。
必须关闭的两个启动开关
Fiber 启动时默认会打印服务地址、彩色日志、完整路由树，这些在压测或生产环境全是冗余开销。尤其路由数超 200 后，EnablePrintRoutes: true 会让初始化慢 100ms+，且无法被缓存。
-
DisableStartupMessage: true—— 干掉那一行 ⇨ http server started on http://localhost:3000 -
EnablePrintRoutes: false—— 路由树不打印，避免反射遍历和字符串拼接 - 别用
fiber.New()默认配置，也别信fiber.Default()；它自带logger和recover中间件，一开就拖垮 QPS
路径参数与请求体要零拷贝访问
Fiber 的性能优势依赖绕过标准库反射和内存分配，一旦走错 API，QPS 直接打七折。
- 取路径参数优先用
c.ParamsInt("id")，不是strconv.Atoi(c.Params("id"))—— 前者内置缓存、不 panic、不分配字符串 - 读请求体用
c.BodyBytes()，不是c.Body()—— 后者返回string，触发底层[]byte → string拷贝 - 解析 JSON 尽量避开
c.BodyParser(&v)，它依赖reflect；结构固定时，用jsoniter.ConfigCompatibleWithStandardLibrary.Unmarshal()预编译
超时控制必须手动设 SetDeadline
fasthttp 不兼容标准 context.Context 的超时机制，c.Context().Done() 在 Fiber 里根本不会触发 cancel，靠中间件统一加 context.WithTimeout 是无效的。
- 每个 handler 开头必须调用
c.Context().SetDeadline(time.Now().Add(3 * time.Second)) - DB 查询、HTTP client、Redis 调用前都要设 deadline，否则 goroutine 卡在 acquire 或 read 上，P99 延迟飙升
- 别用
time.Sleep，它会让整个 goroutine 挂起，不是协程让出；要用time.AfterFunc或异步回调
连接池和 Prefork 不是开得越多越好
Prefork 开启后若未配合内核参数调优（如 net.core.somaxconn），反而会因进程间竞争导致吞吐下降；数据库连接池大小不匹配并发数，goroutine 会在 acquire 上排队阻塞。
-
Prefork: true只在明确需要多进程负载分担时开启，且需搭配SO_REUSEPORT内核支持 - 16 核机器上，pgx 连接池建议设为 32–64，不能直接照搬 CPU 数；观察
pg_stat_activity中 idle_in_transaction 占比 - 静态文件服务慎用
fiber.Static()，高并发下 I/O 成瓶颈；应交由 Nginx 或 CDN 托管
最容易被忽略的是：所有外部调用的超时必须在 handler 内显式控制，而不是依赖中间件或全局 context；因为 c.Context() 是 per-request 的原生 fasthttp context，生命周期与请求强绑定，中间件注入的 timeout 不会穿透到底层 I/O 层。
