ants协程池必须全局初始化，禁止单次请求新建；池大小应按CPU密集型≈NumCPU、IO密集型≈NumCPU×5~20设置，并配WithNonblocking(true)防阻塞，submit后需包装context和recover避免panic泄漏与上下文失效。
ants协程池初始化必须放在全局或init里
直接在 handler 里每次 new 一个 ants.NewPool 是常见错误——这会导致池对象反复创建、GC 压力飙升，且无法复用 worker。实测中，单次请求新建池会把 QPS 拉低 40% 以上。
正确做法是：在 init 函数或服务启动时一次性初始化，并作为全局变量或依赖注入使用：
var pool *ants.Pool
<p>func init() {
var err error
pool, err = ants.NewPool(1000, ants.WithNonblocking(true))
if err != nil {
panic(err)
}
}</p><p>// 后续所有任务都用 pool.Submit(...)
-
ants.NewPool(1000)中的1000不是“最多跑 1000 个 goroutine”，而是池中 worker 的最大数量，超出会按配置丢弃或阻塞 -
WithNonblocking(true)让Submit在满载时不阻塞，而是直接返回 error，需显式处理失败路径 - 不要在 HTTP handler 内部调用
pool.Release()——它会关闭整个池，导致后续请求 panic
池大小设多少？看 CPU 核心数和任务类型
盲目设成 runtime.NumCPU() * 2 或硬写 10000 都容易翻车。池大小本质是资源水位线，不是越大越好。
真实场景中建议分三类设置：
立即学习“go语言免费学习笔记（深入）”；
- CPU 密集型（如加解密、图像缩放）：
池大小 ≈ GOMAXPROCS，通常就是runtime.NumCPU()，再多只会增加调度抖动 - I/O 密集型（如 HTTP 请求、DB 查询）：可设为
NumCPU() * 5 ~ 20，但必须配合超时控制，否则一个慢请求卡住整个 worker - 混合型（如微服务中既调外部 API 又做本地计算）：优先按 I/O 侧瓶颈设，再用
pprof观察goroutines和schedule latency调整
成都物流平台实测发现：当池大小从 500 提到 2000，QPS 反而下降 12%，因为调度器频繁迁移 goroutine 到不同 P 上。
submit 后不等结果？小心 panic 泄漏和上下文失效
pool.Submit(func(){ ... }) 是 fire-and-forget 模式，适合日志上报、埋点等无依赖任务；但若任务内用了 context 或需要错误反馈，就极易出问题。
典型陷阱：
- 传入的
ctx在 submit 瞬间已过期，worker 执行时ctx.Err()已是context.Canceled - 任务里 recover() 失效——
ants默认不捕获 panic，会直接 crash worker，导致池可用 worker 数下降 - HTTP handler 返回后，异步任务还在跑，但
http.Request.Body已被 close，读取直接 panic
安全写法是包装一层带 context 和 recover 的 wrapper：
func safeTask(ctx context.Context, f func(context.Context) error) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in task: %v", r)
}
}()
f(ctx)
}
<p>// 使用
ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)
defer cancel()
pool.Submit(func() {
safeTask(ctx, yourRealWork)
})
别只盯着 goroutine 数，内存分配才是隐性杀手
很多团队优化完池大小、压测 QPS 上去了，一跑几天就 OOM。根源常不在 goroutine 数，而在任务函数里高频 new struct、拼接字符串、json.Marshal —— 这些会快速堆满 young generation，触发 STW GC。
关键动作：
- 对高频小对象（如
bytes.Buffer、http.Header）用sync.Pool缓存，避免每次分配 - 避免在 submit 的闭包里捕获大对象（比如整个
*http.Request），改用必要字段拷贝 - 用
runtime.ReadMemStats定期采样Alloc和NumGC，如果每秒 GC 超过 3 次，基本可以断定是分配问题
蚂蚁金服某支付网关曾因一个未复用的 map[string]string 初始化，导致每秒多分配 8MB 内存，上线 sync.Pool 后 GC 频率从 1.2s/次降到 25s/次。
