应使用 ghz 而非 go test 进行 Fiber 压测，因其不耦合业务代码、完全模拟真实流量；需注意 --insecure 参数、监听地址、启用 fiber.Compress、显式配置 http.Client 连接池及使用 c.SendStatus 等关键优化点。
别用 go test 写压测脚本——它扛不住高并发，也测不准 Fiber 的真实表现。
用 ghz 对运行中的 Fiber 服务直接发压最省事
这是最快验证接口吞吐能力的方式：不改业务代码、不耦合测试框架、完全模拟真实流量。Fiber 启动后监听 :3000，直接跑：
ghz --insecure -z 30s -r 100 http://localhost:3000/api/users
常见错误现象：压测 QPS 上不去、延迟忽高忽低、连接被拒绝——大概率是没加 --insecure（服务启用了 HTTPS 但本地没配证书），或目标地址写成 127.0.0.1 却没监听该地址。
- POST 带 JSON body：
ghz --insecure -d '{"name":"test"}' -m POST http://localhost:3000/api/users - 若接口返回大 JSON，记得提前启用
fiber.Compress中间件，否则网络和序列化会拖垮结果 - Fiber 默认不开启 gzip，
app.Use(fiber.Compress())要显式加，且建议放在路由注册前
手写 net/http + sync.WaitGroup 控制精度更高
适合需要分类统计错误、集成 CI、或复现特定请求节奏的场景。关键不是“能不能发”，而是“能不能稳住”。
- 别用
http.DefaultClient：它默认不限制空闲连接数，压测中容易触发too many open files - 必须显式配置
&http.Client{Transport: &http.Transport{MaxIdleConns: 200, MaxIdleConnsPerHost: 200}} - 用
sync.WaitGroup等待全部 goroutine 完成，别用time.Sleep估时——goroutine 启动有延迟，sleep 不够会提前退出 - Fiber handler 里若只调
c.Status(200)，响应头其实没写出去；压测依赖状态码判断时，得用c.SendStatus(200)或c.JSON(200, data)
Fiber 服务端本身才是压测瓶颈源头
压测结果异常（比如延迟突增、成功率骤降）90% 不是客户端或网络问题，而是 Fiber 服务被自己卡住了。
- 默认启动时带
fiber.Logger()？删掉。它每条请求都同步写日志，QPS 过千就拖垮吞吐 - 路由里写
/:id后再用strconv.Atoi(ctx.Params("id"))？换成ctx.ParamsInt("id")，避免重复解析和 panic 开销 - 频繁调
ctx.Body()？改用ctx.BodyBytes()直接取底层 slice，前提是后续不修改内容 - 中间件里做阻塞操作（如同步 HTTP 调用、未设 timeout 的 DB 查询）？立刻暴露——压测时这些会放大成雪崩点
真正难的不是怎么发起请求，而是怎么让 Fiber 在高并发下不退化：关日志、禁调试、设对 buffer 大小、避免反射、慎用中间件。很多“性能差”的结论，其实只是忘了在 fiber.New() 里加 DisableStartupMessage: true 和 EnablePrintRoutes: false。
