压测前必须关闭Gin调试日志并设为ReleaseMode，否则QPS下降35%以上；ab并发数需分档递进测试，避免连接耗尽；JSON序列化是CPU瓶颈，建议用jsoniter或手写MarshalJSON；中间件应轻量且避免I/O，否则显著增加调度开销。
压测前必须关掉 Gin 的调试日志
默认启动的 Gin 是 debug 模式，会打印完整路由匹配、中间件执行、参数解析等日志，每请求多出约 0.5–2ms 开销，在高并发下直接拖垮 QPS。实测显示：5000 并发时，debug 模式 QPS 比 release 模式低 35% 以上。
正确做法是显式设置运行模式：
func main() {
gin.SetMode(gin.ReleaseMode) // 必须放在 r := gin.Default() 之前
r := gin.New()
// ... 路由注册
r.Run(":8080")
}
注意：gin.Default() 内部已调用 gin.Logger() 和 gin.Recovery()，若不设 mode，即使手动删中间件也拦不住底层调试输出。线上环境漏掉这行，压测结果毫无参考价值。
ab 压测时并发数不是越大越好
ab -n 10000 -c 2000 http://localhost:8080/api 这类命令容易误判性能——-c 设太高，Gin 服务还没瓶颈，TCP 连接队列或本地端口耗尽先报错，常见现象是 apr_socket_recv: Connection reset by peer 或大量 socket: Too many open files。
建议分三档递进测试：
- 先用
-c 50看基线延迟（应 ≤ 5ms），确认单请求无阻塞 - 再试
-c 500，观察 QPS 是否线性增长、平均延迟是否稳定在 10–20ms 区间 - 最后试探
-c 2000，若 QPS 不升反降、延迟跳到 100ms+，说明已触发 Goroutine 调度竞争或系统资源瓶颈，此时要查go tool pprof而不是继续加压
记住公式：QPS = 并发数 / 平均延迟（秒）。比如 -c 1000 测出平均延迟 40ms，理论 QPS 应为 2500；若实测只有 1800，说明存在锁竞争或 GC 停顿干扰。
JSON 序列化是 Gin 接口最常被忽略的 CPU 瓶颈
很多接口返回结构体后直接 c.JSON(200, data)，看似简洁，但 encoding/json 默认会做反射 + 动态类型检查，每请求分配 2–5KB 内存，QPS 上万时 GC 频率飙升。
优化手段有限但有效：
- 用
jsoniter替代原生encoding/json（需提前注册类型），实测降低序列化耗时 40%，内存分配减半 - 对固定结构响应体，手写
MarshalJSON()方法，绕过反射 - 避免在响应中嵌套深层 map 或 interface{}，这类结构强制 runtime 类型推导
特别注意：Gin 的 c.JSON 内部调用的是 json.Marshal，它不缓存反射结果。哪怕同一结构体反复序列化，每次都要重新 inspect 字段——这是压测中延迟毛刺的主要来源之一。
中间件顺序直接影响吞吐量
把耗时操作（如 JWT 解析、数据库查询）放在路由匹配之后、业务 handler 之前，看似合理，但实际会阻塞整个中间件链。Gin 的中间件是同步串行执行的，任一环节卡住，后续所有请求排队等待。
典型错误写法：
r.Use(authMiddleware) // 同步验证 token，含网络请求
r.Use(logMiddleware) // 日志记录
r.GET("/user", userHandler)
正确做法：
- 认证类中间件尽量轻量，token 解析用
jwt-go的ParseUnverified先取 payload，真正鉴权延迟到 handler 内异步做 - 日志中间件用
gin.LoggerWithConfig并关闭Latency中的高精度计时（改用time.Since而非time.Now().Sub()），减少时钟调用开销 - 把 DB 查询、HTTP 调用等 I/O 操作全挪到 handler 里，用
go启协程处理，别塞进中间件
中间件链越长、越重，Goroutine 复用率越低。一个 3 层中间件 + handler 的请求，在 5000 并发下可能比 1 层中间件多占用 30% 的调度开销——这点在 pprof 的 runtime.mcall 占比里非常明显。
