Gin接口高并发变慢主因是业务代码未管控goroutine。具体包括：HTTP调用未设超时、数据库连接池未配置、同步I/O阻塞、中间件滥用、Context未Copy导致竞态、对象未复用引发GC压力。
为什么Gin接口在高并发下变慢？不是框架问题，而是你没管住goroutine
Gin本身不创建goroutine，它完全依赖net/http.Server的默认行为：每个请求进来的瞬间就启动一个新goroutine处理。这意味着——只要你的业务代码不阻塞、不争抢、不泄漏，5000+并发压测时QPS稳定、内存不涨是常态。真正拖慢系统的，几乎全是 handler 里那几行同步调用。
-
http.Get没设context.WithTimeout，一个上游超时就把整个goroutine卡死几十秒 -
*sql.DB全局单例且没调db.SetMaxOpenConns(20)，所有请求排队等连接 - 在handler里直接
os.ReadFile读大文件，同步I/O挂起goroutine - 用
time.Sleep做“简单限流”，等于主动给每个请求加延迟
中间件滥用是性能隐形杀手，尤其Logger和Recovery
默认gin.Default()自带Logger()和Recovery()，看起来省事，但它们会在每个请求路径上强制执行。当QPS上万时，日志格式化+写入（尤其没配异步缓冲）会吃掉可观CPU；而Recovery()虽必要，但panic捕获本身有开销。更危险的是——你在全局r.Use()了某个中间件，结果所有静态资源（/static/xxx）、健康检查（/health）也全被裹进去。
- 只对API路由组注册中间件：
v1 := r.Group("/api/v1"); v1.Use(Auth(), RateLimit()) - 把
Logger()换成带采样率的版本，比如每100个请求只打1条：gin.LoggerWithConfig(gin.LoggerConfig{SkipPaths: []string{"/health"}}) - 避免在中间件里做耗时操作，比如解析JWT后又去查DB验权限——该逻辑应下沉到业务层，或用缓存预热
Context.Copy不是可选操作，而是goroutine安全的硬性门槛
只要你把任何操作扔进go func() { ... }()里，并且里面还要用c.Request、c.Param或c.MustGet，就必须先调c.Copy()。原生*gin.Context不是并发安全的，字段如Keys、Params、Writer在多个goroutine里读写会触发竞态，轻则数据错乱，重则panic崩溃。
- 错误写法：
go func() { log.Printf("uid=%s", c.MustGet("uid")) }() - 正确写法：
cp := c.Copy(); go func() { log.Printf("uid=%s", cp.MustGet("uid")) }() -
Copy()会重置ResponseWriter并清空handlers和Keys，所以别指望副本还能写响应——它只用于读取请求上下文
sync.Pool复用对象，比“优化JSON序列化”见效快十倍
高频接口里反复json.Marshal生成[]byte，或每次请求都new一个结构体，会持续触发GC。Gin内部已大量使用sync.Pool（比如Context实例），但你自己的业务对象得自己管。
立即学习“go语言免费学习笔记（深入）”；
- 定义池：
var userPool = sync.Pool{New: func() any { return &User{} }} - 取用：
u := userPool.Get().(*User); defer userPool.Put(u) - 注意：池中对象可能被GC回收，不能假设状态干净，每次取用后要显式重置字段
- 别池化小对象（如int、string），成本高于收益；重点池化含slice/map/指针的结构体
实际压测中，一个日均百万请求的服务，仅靠池化三个核心DTO，GC次数下降60%，P99延迟从420ms压到110ms——比调优数据库连接池还立竿见影。
