压测fiber.New()默认实例无意义，因其自带Logger、Recover等中间件，I/O开销使QPS暴跌；必须关闭DisableStartupMessage、移除fiber.Logger、慎用Recover，并用wrk配合合理OS与Go参数调优。
直接压测 fiber.New() 默认实例毫无意义——它自带 fiber.Logger、Recover 和请求 ID 中间件，QPS 会被日志 I/O 拖垮一半以上，测出来的数字既不能反映真实能力，也无法指导调优。
压测前必须关掉的三样东西
上线配置 ≠ 压测配置，更不等于默认配置。Fiber 的性能敏感点非常集中，漏掉任意一项都会让结果失真：
-
DisableStartupMessage: true—— 只禁启动横幅，不影响压测；但若你还看到控制台刷日志，说明真正的问题在中间件 -
fiber.Logger()必须移除：它每请求写一次完整 header（含Authorization），实测在 4 核机器上可使 TTFB 增加 0.5ms+，高并发下磁盘 I/O 成瓶颈 -
Recover中间件建议关闭：panic 捕获本身开销不大，但它会强制分配栈帧并记录堆栈，压测时若业务逻辑有误，反而掩盖真实错误路径
用 wrk 测真实吞吐，别信 ab 或 hey
ab 是单线程 HTTP/1.0 工具，hey 默认不复用连接；而 Fiber 的 fasthttp 强依赖连接复用和 pipeline，用它们测等于废掉一半优势。wrk 支持长连接、多线程、Lua 脚本，才是合理选择：
- 基础命令：
wrk -t4 -c400 -d30s http://localhost:3000/health（4 线程、400 并发、30 秒） - 测 JSON 接口时加
-s执行 Lua 脚本，模拟真实 body 发送，避免服务端因空 body 路径优化产生偏差 - 务必加
--latency参数，关注 99% 延迟而非平均值——Fiber 在 2–5 万 QPS 区间常出现延迟毛刺，这是 OS socket 队列或 GC 尖刺信号
路由和参数解析方式决定 QPS 上限
同一台机器、同一压测工具，仅改两行代码，QPS 可能差 3 倍：
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
- 用
app.Get("/user/:id", handler)，别用正则路由app.Get("/user/*", handler)—— 后者匹配慢 3–5 倍，且无法利用 Fiber 的预编译路由表 - 取路径参数用
c.ParamsInt("id")，不是strconv.Atoi(c.Params("id"))—— 前者带缓存、跳过 panic，后者每次调都触发类型断言+错误分配 - 返回 JSON 直接
c.JSON(200, data)，别先json.Marshal再c.Send—— Fiber 内部用了预分配 buffer 和unsafe.String转换，快 20%+ 且零额外 alloc
别让 OS 和 Go 运行时拖后腿
Fiber 自身不卡，但 Linux 默认参数和 Go GC 会在 3 万并发左右开始反噬：
- 检查
/proc/sys/net/core/somaxconn，至少设为65535；否则大量连接堆积在 accept 队列，wrk 显示 timeout 升高 - 启动前加
ulimit -n 100000，否则 open files 不足直接报too many open files - Go 程序启动时加
GODEBUG=gctrace=1观察 GC 频率，若每秒多次 STW，说明对象分配过猛——大概率是你用了c.Body()或频繁json.Unmarshal
真正卡住性能的从来不是框架选型，而是你没意识到 c.ParamsInt() 和 strconv.Atoi() 的差别有多大，也没想到 ulimit -n 没调会导致 wrk 报错全是 connection reset。压测不是比谁数字大，是比谁最先发现链路里最弱的那根弦。
