直接用go启动协程不总是够用，因无节制创建会导致内存暴涨（每goroutine≥2KB）、调度器压力陡增、GC开销上升乃至OOM；协程池通过复用实例、可控并发与超时回收解决该问题，ants库是经生产验证的优选方案。
为什么直接用 go 启动协程不总是够用
当并发任务量大且生命周期短（比如处理数千个 HTTP 请求、批量数据库查询），无节制地 go func() {...}() 会导致 goroutine 泄漏、调度器压力陡增、内存占用失控。Go 运行时虽轻量，但每个 goroutine 至少占用 2KB 栈空间，上万 goroutine 就是 20MB+ 内存，且 GC 扫描成本上升。这不是理论瓶颈——线上服务在突发流量下因 goroutine 爆炸而 OOM 或延迟飙升很常见。
协程池本质是复用 goroutine 实例，把“创建/销毁”换成“取用/归还”，关键约束是：池大小需可配、任务提交要非阻塞或可控阻塞、空闲 goroutine 应能超时回收。
ants 是最稳妥的开箱即用选择
社区中 ants（github.com/panjf2000/ants）经过大量生产验证，API 简洁，内存和调度控制精细。它不是简单封装 chan，而是用链表管理 worker、带心跳检测、支持拒绝策略和 panic 捕获。
使用要点：
- 初始化时指定
capacity（最大并发数），例如ants.NewPool(100)；超过该数的任务默认排队，不会新建 goroutine - 提交任务用
pool.Submit(func())，返回error—— 若池已满且拒绝策略为Deny，会返回ants.ErrPoolOverload - 务必调用
pool.Release()关闭池，否则 worker goroutine 不会退出，造成泄漏 - 若任务可能 panic，
ants默认 recover，但错误日志需自行配置ants.WithPanicHandler
示例片段：
pool, _ := ants.NewPool(50)
defer pool.Release()
<p>for i := 0; i < 1000; i++ {
task := func() {
time.Sleep(10 * time.Millisecond)
}
if err := pool.Submit(task); err != nil {
// 处理拒绝情况，比如降级为同步执行
task()
}
}手写简易池要注意 chan 的死锁与饥饿
很多人用 chan struct{} 做信号量模拟池，但极易出错。典型反模式：make(chan struct{}, N) + 每次 select { case ch 提交任务 —— 这根本没复用 goroutine，只是限制并发数，worker 仍是一次性。
正确手写需分离“任务队列”和“worker 循环”：
- 用
chan func()作为任务队列，容量可设（如make(chan func(), 1000)），避免无限堆积 - 启动固定数量 worker：每个 worker 用
for f := range taskCh { f() }持续消费 - 关闭池时，需先关闭
taskCh，再sync.WaitGroup等待所有 worker 退出；否则range永不结束 - worker 内部必须 recover，否则一个 panic 会让整个 worker 退出，池容量悄悄缩水
关键陷阱：taskCh 若无缓冲且提交端不带 select 超时，提交者会永久阻塞；若缓冲区满又没设拒绝逻辑，任务就丢了。
性能敏感场景要关掉 ants 的日志和检查
ants 默认开启运行时状态检查（如每秒统计 goroutine 数）和详细日志，对 QPS 过万的服务会造成可观开销。压测时发现 CPU 花在 runtime.ReadMemStats 和 fmt.Sprintf 上很常见。
优化方式：
- 初始化时传
ants.WithDisablePanicRecovery(true)（若业务已做 recover） - 用
ants.WithNonblocking(true)让Submit在池满时立即返回 error，避免排队等待 - 禁用指标上报：
ants.WithMetrics(false)，并确保没调用pool.Tuning()动态调参 - 若确定池大小恒定，可跳过
ants.WithExpiryDuration，省去定时器唤醒
这些开关不改变功能，只去掉监控毛刺。真实瓶颈往往不在池本身，而在任务内部 IO 或序列化 —— 协程池只是把问题从“崩掉”变成“暴露得更准”。
