Gin不自带协程池，因其本质是基于net/http的轻量级路由与中间件框架，遵循“每请求一goroutine”设计哲学；协程池属业务层调度职责，需自行集成如gopool等库实现可控并发。
Gin 默认每个请求启动一个 Goroutine，这在高并发下容易导致 Goroutine 泛滥、内存暴涨甚至 OOM。直接靠 runtime.GOMAXPROCS 或调大系统资源不是根本解法——得控制并发任务的生命周期，协程池是目前最可控、生产验证有效的手段。
为什么 Gin 不自带协程池？
Gin 本质是 HTTP 路由和中间件框架，它复用 net/http 的底层服务逻辑，而 net/http 的设计哲学是“每个请求一个 Goroutine”，由 Go 运行时调度器自动管理。这种模型轻量、简单、适合多数场景；但当业务逻辑包含阻塞 IO（如慢 DB 查询、第三方同步调用）、或需强限流时，就容易失控。
协程池不是 Gin 的职责，而是业务层需要主动介入的调度策略。你不会在 gin.Engine 上找到 SetWorkerPool 方法，它必须自己封装或引入第三方库（如 gopool、ants）。
如何用 gopool 实现 Gin 请求级协程复用？
参考 gh_mirrors/ne/new-api 项目中的实践，核心是把耗时逻辑从主 Goroutine 中剥离，交由预热好的协程池执行，并确保 panic 可捕获、上下文可透传。
- 初始化全局池时不要设
math.MaxInt32作为最大数——这等于没限流，应根据压测结果设合理上限（如 100–500），例如：gopool.NewPool("api_pool", 200, config) - 提交任务用
relayGoPool.RelayCtxGo(ctx, taskFunc)，而非裸go taskFunc()；这样能继承ctx的超时与取消信号 - 务必注册
SetPanicHandler，否则协程内 panic 会静默吞掉，日志里只看到连接断开或空响应 - 避免在池中任务里调用
c.Abort()或写响应体——*gin.Context不跨 Goroutine 安全，只能在原始 Handler 中完成响应
典型错误写法：go func() { c.JSON(200, data) }() —— 这会导致竞态或 panic。
哪些接口该上协程池？哪些不该？
协程池不是银弹，滥用反而增加调度开销。判断依据只有一个：该 Handler 是否存在「可预测的阻塞时间」。
- ✅ 应上池：调用外部 HTTP API、同步写 Redis、执行复杂 SQL（无连接池复用时）、生成 PDF 等 CPU/IO 密集型操作
- ❌ 不该上池：纯内存计算、读本地缓存（如
sync.Map）、返回固定 JSON、JWT 解析等微秒级操作 - ⚠️ 特别注意：数据库操作本身不一定要进池——如果已配置合理大小的
sql.DB.SetMaxOpenConns和SetMaxIdleConns，连接池已承担了复用职责，此时再套一层协程池可能徒增延迟
一个常被忽略的点：协程池里的任务如果又触发了新的 HTTP 请求（比如调用另一个微服务），而那个请求没做超时控制，整个池子可能被卡住。所以 http.Client 必须配 Timeout + Transport 复用。
sync.Pool 和协程池是两回事
有人混淆 sync.Pool（对象复用，减少 GC）和协程池（Goroutine 复用，控制并发）。前者用于反复创建小对象（如 bytes.Buffer、JSON 编码器），后者用于管控长时任务的执行单元。你在 Handler 里用 bufferPool.Get() 是对的，但这不能防止 10k 并发请求瞬间拉起 10k Goroutine。
真正压垮系统的，往往不是内存分配，而是 Goroutine 阻塞后堆积——它们占着栈内存（默认 2KB）、等待锁、等待网络响应，却无法被调度器及时回收。这时候看 pprof/goroutine 会发现数千个状态为 IO wait 或 semacquire 的 Goroutine，这就是协程池该介入的信号。
