直接用 go handle() 会压垮长连接服务，因每连接并发子任务导致 goroutine 泛滥；ants.pool 必须配置 withdynamicadjustment、withexpiryduration、withnonblocking 和 withpanichandler，并按 io/cpu 类型拆池或差异化调参，resize 需由独立监控 goroutine 基于可观测指标触发。
为什么直接用 go handle() 会压垮长连接服务
长连接场景（如 WebSocket、gRPC streaming、HTTP/2 推送）下，每个连接生命周期远长于普通 HTTP 请求，而每个连接内又可能并发处理多个子任务（如消息广播、状态同步、DB 写入）。若对每个子任务都 go handle()，极易在连接数上升时失控：1000 个长连接 × 平均每连接 50 个活跃 goroutine = 5 万个 goroutine —— 内存暴涨、调度延迟飙升、GC 频繁，最终表现为 P99 延迟跳变、连接假死或 OOM。
ants.NewPool 默认不扩容，长连接里必须显式配 WithDynamicAdjustment
很多人以为 ants.NewPool(50) 能“自动扛住突发”，结果压测时 Submit 卡住、pool.Free() 一直为 0、监控里任务排队长度持续上涨。这不是库有问题，而是默认池是固定容量的，根本不会扩容。
- 必须加
ants.WithDynamicAdjustment(true)（v2.8.0+ 才支持） - 必须配
ants.WithExpiryDuration(30 * time.Second)，否则扩容后空闲 worker 不回收，goroutine 数只增不减 - 必须配
ants.WithNonblocking(true)，否则 Submit 在扩容窗口期仍会阻塞，拖垮整个连接协程 - 别漏
ants.WithPanicHandler()，长连接中一个 panic 可能 hang 住整个 worker，造成“假性满载”
长连接任务提交要区分 IO 和 CPU 类型，配不同队列策略
同一个长连接里，既有 DB 查询（IO 密集）、又有 JSON 序列化（CPU 密集），混用一个池会导致资源争抢。建议按类型拆池，或至少差异化配置：
- IO 型任务（如 Redis 调用、下游 RPC）：设
WithMaxBlockingTasks(2000)，允许适度排队，避免频繁降级 - CPU 型任务（如加密、压缩、模板渲染）：设
WithMaxBlockingTasks(200)或直接WithNonblocking(true)，防单个任务拖慢整池 - 所有池都配
WithPreAlloc(false)—— 长连接服务启动时无法预估负载，冷启动扩容比预分配更合理
pool.Resize() 不能在连接 handler 里调，得靠独立监控 goroutine
长连接服务里，你没法在 http.HandlerFunc 或 websocket.OnMessage 中安全调 pool.Resize()：它会触发内部锁竞争，实测连续调 3 次就让 Submit 平均耗时从 0.02ms 涨到 1.2ms；而且 resize 是懒启动，新 worker 不会立刻干活，对当前积压无缓解。
正确做法是起一个独立 goroutine，周期采样关键指标：
- 当
pool.Free() == 0 && len(queue) > pool.Cap()*2持续 5 秒 →pool.Resize(min(pool.Cap()*1.25, maxWorkers)) - 当
pool.Free() == pool.Cap() && pool.Running() == 0持续 60 秒 → 缩容回基础值 - 每次 resize 后 sleep 至少 10 秒，避免抖动
真正难的不是写几行 resize 代码，而是把“扩容时机”从拍脑袋变成可观测、可验证的信号 —— 队列长度、Free() 变化率、下游 P95 延迟，这些才是决定要不要动池子的依据。
