strictrouting 关闭后实际更慢，因需额外执行尾部斜杠归一化、301重定向生成及字符串拼接；开启后为纯字符串前缀比对，radix树直接跳转，无同步开销。
StrictRouting 关闭后路由匹配变慢？其实它更快
StrictRouting 默认开启不是为了“限制你”，而是避免隐式归一化带来的开销。关掉它不会提升性能，反而可能引入歧义和匹配错误。
常见错误现象：关闭 StrictRouting 后，/users 和 /users/:id 同时注册，请求 /users/123 被前者捕获，ctx.Params("id") 拿不到值。
- StrictRouting = true 时，路径匹配是纯字符串前缀比对，Radix 树直接跳转，无额外计算
- StrictRouting = false 会触发尾部斜杠自动归一（如
/users/→/users），再做一次查找，多一次 O(k) 操作 - 更推荐显式注册
/users和/users/:id，或用中间件统一 301 重定向，而非全局关掉
Prefork 开启后 QPS 翻三倍，但别忘了 ulimit 和状态隔离
Prefork 是 Fiber 在生产环境释放多核性能最直接的方式，但它不是“开箱即用”的银弹。
典型错误：在 8 核机器上启用 Prefork，但系统 ulimit -n 仍为默认 1024，导致大量连接被拒绝，压测结果远低于预期。
- 必须调高文件描述符限制：
ulimit -n 65536（或写入/etc/security/limits.conf） - 各子进程内存完全隔离，
sync.Map或全局变量无法跨 worker 共享，缓存类逻辑需改用 Redis / shared memory - 启动日志中会出现多个
Worker PID: xxx，若只看到一个，说明 Prefork 未生效（检查是否在app.Listen()前传入了正确 config）
ctx.Body() 和 strconv.Atoi() 是隐形吞吐杀手
Fiber 底层复用 fasthttp 的内存池，但标准库惯用写法会绕过所有优化，让高并发场景迅速退化成 net/http 水平。
实测对比（4 核 8G，10K 并发）：ctx.Body() 导致 GC 频次上升 3.2 倍，P99 延迟从 8ms 涨到 47ms。
- 改用
ctx.BodyBytes()直接取[]byte引用，前提是不修改内容（修改需先copy()） - ID 类参数解析别反复调
strconv.Atoi(ctx.Params("id"))，应在中间件里一次性解析并存入ctx.Locals - 避免在 handler 中拼接字符串、使用
fmt.Sprintf，改用bytes.Buffer或预分配[]byte
fiber.Default() 上线即踩坑，New() + 显式中间件才是生产姿势
fiber.Default() 是开发快捷键，不是生产配置。它自带的 Logger、Recover、RequestID 会在高并发下成为瓶颈。
常见后果：Logger 默认打印完整请求头（含 Authorization），每秒数百条日志直接拖垮磁盘 I/O；Recover 中 panic 日志未限流，一次雪崩引发全量刷屏。
- 上线必须用
fiber.New(&fiber.Config{...})，手动挂载需要的中间件 - Logger 若保留，需配置
DisableHeader: true和Format字段精简输出 - Recover 中间件建议加
if os.Getenv("ENV") == "prod"条件控制，或替换为 Sentry 集成
