协程池是为控制资源争抢和避免goroutine泄漏而设的显式限流机制，非所有场景都适用；ants库最成熟，手写需注意缓冲channel、panic捕获及关闭顺序。
为什么直接用 go 启动协程容易出问题
不是所有任务都适合无节制地 go func() {}()。当并发量突增（比如每秒上千请求），大量 goroutine 会迅速耗尽内存、触发调度器压力，甚至因 channel 阻塞或未回收导致 goroutine 泄漏。Go 的 runtime 确实能管理百万级 goroutine，但那是“能跑”，不是“该这么跑”——尤其当每个协程实际执行的是 IO 密集型或带资源申请（如 DB 连接、文件句柄）的任务时。
协程池本质是控制并发度的显式节流机制，它不消灭 goroutine，而是复用 + 限流：
- 避免瞬时创建/销毁开销（虽然很小，但高频下可观）
- 防止资源类任务被过度争抢（例如一个池配 10 个 DB worker，就永远最多占 10 个连接）
- 让错误处理和超时控制更集中（统一在池层做
context.WithTimeout或 recover）
ants 库是最省心的协程池选择
自己手写带缓冲、带 panic 捕获、带超时取消、带统计的池容易漏边界条件。ants（https://github.com/panjf2000/ants）是目前最成熟的第三方实现，已被大量线上服务验证。
典型用法：
立即学习“go语言免费学习笔记（深入）”；
pool, _ := ants.NewPool(50) // 最多 50 个并发 worker
defer pool.Release()
<p>for i := 0; i < 1000; i++ {
_ = pool.Submit(func() {
// 实际任务，比如 HTTP 调用或 DB 查询
time.Sleep(time.Millisecond * 10)
})
}关键点：
-
NewPool(n)中的n是硬上限，超出任务会阻塞在Submit，除非你用NewPoolWithFunc(n, fn)配合带缓冲的 channel 做异步丢弃 -
Submit返回error：仅当池已关闭或任务提交被拒绝（如非阻塞模式下队列满）时才非 nil - 默认不捕获 panic，需手动包装：
pool.Submit(func() { defer func(){_ = recover()}(); doWork() })
不用第三方库时，如何手写最小可用协程池
核心结构只有三样：任务 channel、worker 数量控制、关闭信号。不需要泛型、不用复杂状态机。
type Pool struct {
tasks chan func()
done chan struct{}
}
<p>func NewPool(workerNum int) *Pool {
p := &Pool{
tasks: make(chan func(), 1024), // 缓冲区防压测瞬间打爆
done: make(chan struct{}),
}
for i := 0; i < workerNum; i++ {
go p.worker()
}
return p
}</p><p>func (p *Pool) Submit(task func()) {
select {
case p.tasks <- task:
case <-p.done:
// 可选：记录日志或 panic
}
}</p><p>func (p *Pool) worker() {
for {
select {
case task := <-p.tasks:
// 推荐加 recover，否则一个 panic 会让整个 worker 退出
defer func() { _ = recover() }()
task()
case <-p.done:
return
}
}
}</p><p>func (p *Pool) Release() {
close(p.done)
close(p.tasks)
}注意几个易错点：
- 不要在
worker()外层用recover——它捕获不到子 goroutine 的 panic -
taskschannel 必须带缓冲，否则第一个Submit就会阻塞，池无法启动 -
Release()中先关done再关tasks，否则可能漏掉最后一批任务
协程池不适合什么场景
协程池不是银弹。以下情况强行套用反而增加复杂度：
- 任务生命周期极短且无资源依赖（比如纯计算型 map-reduce 中的单次加法）——此时
go开销远小于池调度成本 - 任务执行时间差异极大（有的 1ms，有的 10s），且无法预估分布——固定 worker 数会导致长任务阻塞短任务队列
- 需要精确控制每个任务的上下文生命周期（如每个请求绑定独立
context.Context）——池内 worker 是复用的，必须把 context 显式传入 task 闭包，而非依赖外部作用域
真正关键的判断点在于：你限制并发，是为了控资源，还是仅仅怕“goroutine 太多”？前者需要池，后者多半是误解。
