Fiber实测QPS比Gin高约30%，但需禁用fiber.Default()默认中间件、手动精简配置；启用StrictRouting、复用http.Client并优化参数解析（如用BodyBytes/ParamsInt）才能释放性能优势。
实测 QPS 比 Gin 高约 30%，但前提是关掉默认中间件
Fiber 确实快，不是营销话术——在相同 JWT 验证逻辑、相同硬件（4 核 8G）下，压测 /api/ping 接口，Fiber 实测 QPS 稳定在 28k–32k，Gin 在 21k–24k 区间。但这个差距只在你用 fiber.New() + 手动挂载必要中间件时成立。一旦误用 fiber.Default()，Logger 和 Recover 会把 TTFB 拉高 0.3–0.8ms，QPS 直接回落到 22k 左右，和 Gin 拉不开差距。
关键点在于：fiber.Default() 自带日志、panic 恢复、RequestID，开发方便，上线就是性能毒药。上线前必须切回 fiber.New(&fiber.Config{...})，只加 logger.New()（且禁用敏感头输出）、recovery.New()（不打印堆栈），其他全按需手写。
ctx.Body() 和 strconv.Atoi 是隐形吞吐杀手
很多人写 ctx.Body() 读请求体、strconv.Atoi(ctx.Params("id")) 解析参数，看着没问题，一上压测就掉 QPS。原因：前者触发底层 buffer 拷贝，后者强制字符串分配+类型转换，彻底绕过 fasthttp 的零拷贝设计。
- 改用
ctx.BodyBytes()直接取[]byte引用（别改内容） - ID 类型参数优先用
ctx.ParamsInt("id")或ctx.QueryInt("page")，它们内部用fasthttp原生解析，无额外分配 - JSON 解析别用
json.Unmarshal(ctx.Body(), &v)，换成ctx.BodyParser(&v)，它复用预分配缓冲区
StrictRouting=true 反而更快，别急着关
看到 /users 和 /users/ 404 就去关 StrictRouting？这是典型误区。StrictRouting: true 下，Fiber 路由匹配是纯指针跳转，O(k) 时间完成，不拼接、不重定向、不 fallback；而 false 会触发尾部斜杠归一化 + 可能的 301 生成，多出至少两次字符串操作和一次响应构造。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实测开启 StrictRouting 后，P95 匹配延迟稳定在 12–15μs；关闭后升至 28–35μs，尤其在路由数 >200 时更明显。真正该做的，是显式注册两种路径，或在反向代理层统一处理（如 Nginx rewrite），而不是在框架层妥协。
HTTP 客户端调用下游才是吞吐瓶颈真凶
本地跑 Fiber QPS 再高，一调外部 HTTP 服务就崩——90% 的“慢”来自你没配对的 http.Client。默认 http.DefaultClient 的 MaxIdleConnsPerHost = 2，10 并发就排队；IdleConnTimeout = 0，连接常被服务端静默断开，下次复用触发重连；没设 TLS 缓存，每次 HTTPS 握手耗时翻倍。
必须全局复用一个定制 client：
var httpClient = &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 90 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
TLSClientConfig: &tls.Config{
ClientSessionCache: tls.NewLRUClientSessionCache(100),
},
},
}
注意：MaxIdleConnsPerHost 要 ≥ 预期峰值 QPS × 平均下游响应时间（秒），比如 100 QPS × 0.1s = 10，但建议从 100 起步，避免连接池争用。
真正卡住吞吐的，从来不是框架本身，而是你把 ctx.Next() 当流程控制、把 http.Get 当胶水、把 fiber.Default() 当上线配置——这些细节不抠，再快的 Radix 树也救不了 P99 延迟。
