直接用ghz压测Fiber服务最轻量真实；go test因生命周期短、无连接复用、无QPS控制，不适合高并发压测，易触发资源耗尽而非暴露服务瓶颈。
直接用 ghz 压测运行中的 Fiber 服务，是最轻量、最真实、最不干扰业务的方式；手写 net/http + sync.WaitGroup 仅在需要精确控制错误分类或集成 CI 时才值得投入——别用 go test 写压测脚本，它天生不适合高并发场景。
为什么不能用 go test 做 Fiber 压测
go test 的 testing.T 生命周期极短，不支持连接复用、无请求速率控制、底层使用 http.DefaultClient（默认无连接池限制），压到几千并发就触发 too many open files 或连接超时。它设计目标是单元验证，不是负载模拟。
- 常见错误现象：
panic: send on closed channel、connection refused频发，但 Fiber 服务本身完全健康 - 压测中看到的失败，90% 是客户端资源耗尽，而非服务端瓶颈
- 即使加了
time.Sleep等待，也无法保证 goroutine 全部完成——必须用sync.WaitGroup显式同步
用 ghz 快速发起真实 HTTP 压测
ghz 不依赖 Fiber 框架代码，不修改任何业务逻辑，直接对监听地址发压，结果反映的是真实网络链路 + Fiber 处理路径的综合表现。
- 安装：
go install github.com/bojand/ghz/cmd/ghz@latest - 基础压测：
ghz --insecure -z 30s -r 100 http://localhost:3000/api/users（30 秒、每秒 100 请求） - 带 JSON body 的 POST：
ghz --insecure -d '{"name":"test"}' -m POST http://localhost:3000/api/users - 注意：
Fiber默认不启用gzip，若返回大 JSON，压测吞吐会受序列化和网络带宽拖累；需显式加app.Use(fiber.Compress(fiber.Gzip))
手写 net/http + sync.WaitGroup 的关键避坑点
适合需要自定义指标采集（如按状态码分桶）、集成到 CI pipeline、或做长连接保活测试的场景。但必须绕过 http.DefaultClient 的默认陷阱。
- 必须显式配置
&http.Client{Transport: &http.Transport{MaxIdleConns: 200, MaxIdleConnsPerHost: 200}}，否则连接池撑不住 - 别用
time.Sleep估算总耗时——sync.WaitGroup是唯一可靠方式 - Fiber handler 中若依赖
c.Status()判断，要确保显式调用c.SendStatus()或c.JSON()，否则响应头未写，压测工具可能收不到状态码 - 避免在 handler 里做阻塞操作（如
time.Sleep、同步文件读写），否则压测延迟突增不是网络问题，而是服务自身被卡住
压测中延迟飙升或成功率骤降，先查这三处
绝大多数“性能差”的结论，其实来自配置误用或观测偏差，而不是 Fiber 本身不行。
- Fiber 启动时没关调试：
fiber.Config{DisableStartupMessage: true, EnablePrintRoutes: false}必加，否则日志刷屏吃 CPU - 中间件没清理：特别是
logger，压测时建议全关，或换异步写入版本；recover放错顺序会导致 panic 后响应头已写，后续中间件失效 - 路由写成正则匹配（如
app.Get("/user/*", handler)）而非参数化（app.Get("/user/:id", handler)），性能差 3–5 倍
真正卡住 Fiber QPS 的，往往不是框架层，而是你没设 SetDeadline 导致连接 hang 住、JSON 解析用 c.BodyParser() 触发反射、或者静态文件走中间件而非 app.Static() 直出——这些细节比选 Gin 还是 Fiber 影响更大。
