Gin框架本身性能优异，瓶颈几乎全在业务代码：中间件滥用、阻塞调用、JSON序列化开销、对象频繁分配、连接池缺失；应按需挂载中间件、禁用非必要中间件于健康检查/静态路由、严格控制外部调用超时与数据库连接池、用jsoniter替代标准JSON库、善用sync.Pool复用高频小对象，并以pprof精准定位真实瓶颈。
Gin 框架本身不拖后腿，性能瓶颈几乎全在代码层：中间件滥用、阻塞调用、JSON 序列化开销、对象频繁分配、连接池缺失——这些才是真实压垮 QPS 的元凶。
为什么 c.JSON(200, data) 会悄悄拉低吞吐？
标准 c.JSON() 内部用 encoding/json + 反射 + 堆分配，高频接口每秒几百次调用，会显著抬高 GC 频率，延迟波动明显。
- 替换为
github.com/json-iterator/go，初始化一次：var json = jsoniter.ConfigFastest - 对固定结构体（如
type UserResponse struct{...}），提前用json.Marshal编码成[]byte，再用c.Data(200, "application/json", bytes)直接写入响应体 - 避免在 handler 中反复构造
gin.H，它本质是map[string]interface{}，每次 new 都触发堆分配
sync.Pool 复用什么对象最有效？
不是所有对象都值得放 Pool；高频、短生命周期、结构稳定的小对象收益最大。比如 JSON 解码缓冲区、bytes.Buffer、自定义请求上下文载体等。
- 别复用带状态的指针（如已赋值的
*http.Request或*gin.Context），会引发数据竞争 - 典型安全用法：
bufferPool.Get().(*bytes.Buffer).Reset()，用完defer bufferPool.Put(buf) - 中间件里解析 JWT payload、校验签名时生成的临时 map，也适合 Pool 化
中间件挂载位置错误，比没写还危险
全局注册 router.Use(AuthMiddleware(), Logger()) 意味着每个请求（包括 /healthz、/static/js/app.js）都强制走完整链路，白白消耗 CPU 和 goroutine 调度资源。
- 静态资源路由必须跳过所有中间件：
r.StaticFS("/static", http.Dir("./static")) - 健康检查接口直接裸写：
r.GET("/healthz", func(c *gin.Context) { c.Status(200) }) - 按需分组挂载：
v1 := r.Group("/api/v1").Use(AuthMiddleware()); v1.GET("/users", handler) - 日志中间件建议只打关键字段（method、path、status、latency），避免序列化整个
c.Request
数据库和 HTTP 外部调用，超时和连接池缺一不可
没设超时的 http.Get() 或未配池的 db.QueryRow()，会让 goroutine 卡住，表面不影响其他请求，实则快速耗尽 DB 连接或堆积 pending 请求。
- HTTP 调用必带 context：
ctx, cancel := context.WithTimeout(c.Request.Context(), 800*time.Millisecond)，用完立刻cancel() - MySQL/PostgreSQL 连接池至少设三项：
db.SetMaxOpenConns(50)、db.SetMaxIdleConns(10)、db.SetConnMaxLifetime(30 * time.Minute) - 别在 handler 里直接
go func() { ... }()调外部服务——忘了传c.Copy()就会读到空或错乱的上下文数据
真正卡顿的地方，往往藏在看似“无害”的一行 c.JSON()、一个没关的 defer rows.Close()、或一个被忽略的 router.Use() 里。调优不是堆参数，而是顺着 pprof 找出那几个占 CPU 30% 或分配内存最多的函数，然后精准替换或复用。
