wrk压测比go test -bench更真实，因后者不走tcp栈、忽略连接复用与gc压力；需用wrk -t10 -c5000 -d30s模拟真实并发，禁用日志、调高ulimit，关注qps、p99延迟、rss内存峰值。
用 wrk 做真实并发压测，别只信 go test -bench
基准测试（go test -bench）能反映单请求路径的开销，但掩盖了连接复用、GC压力、上下文切换等高并发真实瓶颈。比如 BenchmarkGin 可能显示 120k QPS，但 wrk 在 5w 并发下实际跌到 85k——因为 httptest.NewRecorder 不走 TCP 栈，不触发 netpoller 调度竞争。
- 必须用
wrk -t10 -c5000 -d30s http://localhost:8080/ping模拟真实连接池和 keep-alive 行为 - 禁用框架日志中间件（如
gin.Logger()），否则延迟虚低、QPS 虚高 - 压测前加
ulimit -n 100000，否则 Linux 默认 1024 文件描述符会直接报connect: cannot assign requested address
关注三个硬指标：QPS、P99 延迟、RSS 内存峰值
只看平均延迟（avg latency）容易误判——某次 GC STW 可能让 1% 请求卡在 200ms，而 avg 还是 2ms。生产环境更怕长尾，不是均值。
-
QPS：wrk 输出的Requests/sec，注意对比时统一用-d30s（避免冷启动偏差） -
P99 延迟：wrk 的Latency Distribution表中 99% 行数值，比 avg 更敏感 -
RSS 内存：用ps -o rss= -p $(pgrep -f 'main') | awk '{sum+=$1} END {print sum}'抓压测中峰值，echo 常比 Gin 少 2–3MB，因echo.Context零分配
路由复杂度一上来，net/http 和 Gin 差距就收窄
简单 GET /ping 测试里 Gin 比 net/http 快 15%，但一旦加 50 条带参数路由（如 /users/:id/posts/:pid），Radix Tree 查找开销摊薄了框架差异，此时 GC 压力和中间件链长度反而成主导。
- 测试多路由场景务必用
RouteN模式（参考golang-mux-benchmark项目） - 避免在中间件里做
json.Unmarshal或 DB 查询——这会让框架选型影响归零，瓶颈移到 I/O 层 -
Gin的gin.Context复用虽省内存，但若中间件频繁调用c.Set("key", val)，仍会触发 map 扩容，实测 P99 延迟上升 8%
别忽略 fasthttp ——它快但不兼容 net/http 生态
fasthttp 在百万并发下常比 Gin 高出 2–3 倍 QPS，核心是绕过 net/http 的 request/response 对象分配，直接操作字节切片。但它不支持 http.Handler 接口，所有中间件、Prometheus、OpenTelemetry 适配器都得重写。
立即学习“go语言免费学习笔记（深入）”；
- 如果你用
gorilla/sessions或chi/middleware，切fasthttp等于重写半套生态 -
fasthttp的RequestCtx是栈上复用，不能跨 goroutine 传递，go func() { c.String(...) }()会 panic - 真要榨干性能：先用 Gin + pprof 定位瓶颈；若 70% 时间花在
net/http.serverHandler.ServeHTTP，再考虑换fasthttp
框架性能差距从来不在“谁更快”的标签上，而在你压测时是否关掉了调试日志、是否让 GC 在压测中完成了三次 full sweep、以及你写的那行 c.BindJSON(&v) 实际分配了多少对象——这些细节比框架名字重要得多。
