直接用goroutine处理短连接会因瞬时创建海量goroutine导致调度开销激增、内存飙升和GC频繁停顿；ants协程池通过复用worker、限制并发数、设置超时与panic恢复来控制资源水位、避免雪崩并提升可观测性。
为什么直接用 goroutine 处理连接会出问题
短连接爆发时，go handleConn(conn) 会瞬间拉起成百上千 goroutine，调度开销陡增，内存占用飙升，甚至触发 GC 频繁停顿。这不是“并发能力强”的体现，而是失控的信号——尤其当 handleConn 内部有阻塞 I/O、数据库查询或 HTTP 调用时，goroutine 实际处于休眠态，但依然占着栈和调度元数据。
协程池不是为了“限制并发”，而是为了：控制资源水位、避免雪崩、让错误可观察（比如池满时主动拒绝而非卡死）。
golang.org/x/sync/errgroup 不是协程池，别误用
errgroup.Group 只负责协同取消和错误传播，它不管理 goroutine 生命周期，也不限流。你写 eg.Go(func() error { ... })，照样会无节制启新 goroutine。
真正需要的是带缓冲的任务队列 + 固定 worker 数量的运行时结构。常见误区：
- 用
semaphore.Weighted做“伪池”：只能控数量，无法复用 goroutine，任务排队时仍要频繁创建/销毁 - 手写 channel + for-select 循环但没做 panic 恢复：一个 worker panic 会导致整个池静默退出
- worker 从队列取任务后不设超时：单个慢请求拖垮全池
用 panjf2000/ants 快速落地，但注意三个配置点
这是目前最轻量、生产验证过的 Go 协程池库。核心是 ants.NewPool 和 pool.Submit。关键配置项必须显式设置：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
ants.WithNonblocking(true)：提交任务时若池满，Submit立即返回 false，而不是阻塞。必须检查返回值，否则静默丢任务 -
ants.WithExpiryDuration(10 * time.Second)：空闲 worker 超时回收，防长连接场景下 goroutine 泄漏 -
ants.WithPanicHandler(func(p interface{}) {...})：务必设置！否则 worker panic 后该 goroutine 消失，池容量永久减少
示例片段：
pool, _ := ants.NewPool(50, ants.WithNonblocking(true))
defer pool.Release()
<p>connHandler := func(conn net.Conn) {
defer conn.Close()
// 处理逻辑...
}</p><p>// 提交前必须检查
if ok := pool.Submit(func() { connHandler(conn) }); !ok {
http.Error(w, "service busy", http.StatusServiceUnavailable)
return
}
自研简易池要注意 runtime.Gosched() 的位置
如果不用第三方库，最小可行池只需一个 chan func() 和固定数量的 for-select 循环。但有一个隐蔽坑：for { select { case f := 在任务执行时间极短时，可能让单个 worker 抢占调度器过久，导致其他 worker 饿死。
解决方案是在每次任务执行后加 runtime.Gosched()（非强制，但推荐）：
for {
select {
case f := <-p.taskCh:
f()
runtime.Gosched() // 让出时间片，提升公平性
case <-p.stopCh:
return
}
}
更关键的是：池的 Submit 方法必须是非阻塞且带超时的 context 控制，否则上层 HTTP server 的 ReadTimeout 无法传导到池任务层面。
真正难的不是启动几个 goroutine，而是让它们在负载波动、panic、超时、关闭过程中始终可预测地响应。这点上，连 ants 的默认配置都不够鲁棒，得自己补全监控和熔断逻辑。
