sync.Pool不适合协程池场景，因其仅为临时对象复用设计，不提供并发控制、数量限制、任务排队或生命周期管理能力；真正协程池需基于chan func() + sync.WaitGroup实现任务分发与worker管控。
为什么直接用 sync.Pool 不适合协程池场景
sync.Pool 是为临时对象复用设计的，不是为控制并发执行而生。它不保证对象数量、不管理生命周期、也不提供等待或限流能力。如果你试图用它来“池化 goroutine”，会发现根本没法控制启动时机、无法回收正在运行的协程、更没法做任务排队——它连 Go 的 goroutine 本体都管不了，只管你塞进去的任意值。
真正需要的是一个带任务队列、可配置初始/最大容量、能动态启停 worker 的结构体，而不是对象缓存工具。
核心结构：用 chan 做任务分发 + sync.WaitGroup 管理活跃 worker
最轻量且可控的方式是：用无缓冲或带缓冲的 chan func() 当任务队列，每个 worker 是一个死循环 for range 读取该 channel；用 sync.WaitGroup 跟踪当前活跃 worker 数，并配合 sync.Mutex 控制扩容逻辑。
关键点：
- 任务 channel 必须是
chan func()，不能是chan interface{}，避免运行时类型断言开销和 panic 风险 - worker 启动后立即
wg.Add(1)，退出前wg.Done()，否则Wait()会永远阻塞 - 扩容判断必须在加锁下读取当前 worker 数并比较阈值，否则并发修改会导致重复启动或漏扩
- 不要在 worker 内部再起 goroutine 处理任务——那等于放弃池控权，直接退化成无限制
go f()
如何安全触发自动扩容：基于任务积压与空闲 worker 比例
纯看 worker 数量扩容容易误判（比如所有 worker 都卡在 IO 上，但任务没积压）；纯看 channel 长度又忽略处理能力。更实用的策略是：当任务 channel 长度 > 阈值 且 当前活跃 worker 数
示例逻辑片段：
if len(p.taskCh) > p.highWaterMark && atomic.LoadInt32(&p.workers) < p.maxWorkers {
p.mu.Lock()
if atomic.LoadInt32(&p.workers) < p.maxWorkers {
go p.startWorker()
atomic.AddInt32(&p.workers, 1)
}
p.mu.Unlock()
}
注意：len(p.taskCh) 只对带缓冲 channel 有效；无缓冲 channel 的长度恒为 0，此时得换指标，比如记录最近 1s 内入队数与完成数的差值。
关闭与等待：避免 panic 和 goroutine 泄漏
关闭池不能简单 close(channel)，因为 worker 还在 for-range 中读取，close 后会立刻退出，未执行完的任务就丢了。正确做法是：用一个 done chan struct{} 通知所有 worker 优雅退出，并确保所有已入队任务被执行完毕。
关闭流程应包含：
- 关闭
donechannel，让 worker 检测到后跳出 for 循环 - 把剩余任务从
taskCh中 drain 出来，逐个执行（不能丢） - 调用
wg.Wait()等待所有 worker 彻底退出 - 最后再 close(
taskCh)，防止后续误提交
如果业务要求“关闭时丢弃未执行任务”，那得在 drain 前加开关判断，但这是例外场景，不是默认行为。
最容易被忽略的是：worker 内部调用的函数如果 panic，会直接杀死该 worker，导致池容量永久减少。务必在 worker 循环里加 defer/recover，并记录日志，否则扩容逻辑可能反复失败却无感知。
