直接用go func()启动大量协程极易触发栈溢出或OOM，协程池核心是硬性约束并发数；最简方案用带缓冲chan func()、固定worker和显式关闭机制，50行内可实现。
直接用 go func() 启动大量协程，在真实服务中大概率会触发 runtime: goroutine stack exceeds 1GB limit 或系统 OOM，不是理论风险，是线上高频事故。协程池不是“炫技”，而是对并发数的硬性约束——它只解决一个问题：不让 goroutine 数量失控。
为什么带缓冲的 chan func() 是最简可行方案
不用第三方库、不引入额外依赖，50 行内就能跑通一个可关闭、线程安全、非阻塞提交的基础池。核心就三点：一个带缓冲的任务 channel、一组常驻 worker、一个显式关闭机制。
-
make(chan func(), queueSize)必须设缓冲，否则pool.Submit()可能永远卡住；建议queueSize = capacity * 5，太小易丢任务，太大内存浪费 - worker 用
for task := range tasks消费，channel 关闭后自动退出循环，但必须配合sync.WaitGroup等待已启动的 worker 结束 - 关闭时先
close(tasks)阻止新任务入队，再wg.Wait()确保所有正在执行的 task 完成——这不是“优雅退出”，是底线要求
ants.NewPool() 为什么是生产环境首选
手写池在压测或突发流量下容易暴露盲区：panic 被吞、空闲 worker 不回收、满负荷时无拒绝策略、无法动态调参。而 ants 把这些都收口了。
- 初始化时传
capacity（如ants.NewPool(100)），超过该数的任务默认排队，绝不会新建 goroutine - 提交失败时返回明确错误
ants.ErrPoolOverload，你可以立刻降级为同步执行，而不是让调用方死等 - 必须调用
pool.Release()，否则 worker goroutine 永不退出——这是最容易漏掉的一行，一漏就是泄漏 - 默认 recover panic 并记录日志，但日志 handler 需手动配
ants.WithPanicHandler()，否则看不到错误上下文
用 chan struct{} 模拟信号量是典型误区
很多人写 sem := make(chan struct{}, N)，每次提交前 sem ，执行完再 <code><-sem。这根本不是协程池，只是并发数限制器：每个任务仍启动一个新 goroutine，worker 不复用，GC 压力照旧。
立即学习“go语言免费学习笔记（深入）”；
- 真正复用，意味着同一个 goroutine 执行多个任务，靠的是「固定数量的 for-range 循环 + 共享 channel」
- 信号量方式无法控制任务排队、无法反馈执行结果、无法统一处理 panic，连基础背压都没有
- 它适合极简单场景（比如限速 HTTP client），但一旦要监控、统计、超时、熔断，立刻崩盘
协程池真正的复杂点不在启动，而在关闭和错误传播路径。比如 Submit() 返回 error 后，你是否确保上层不会继续往已关闭的 channel 发送？是否所有 panic 都能被观测到？这些细节不处理，池子建得再漂亮，也是线上定时炸弹。
