直接用 go 启动协程易导致 OOM 或系统限流，因 goroutine 虽轻量但栈空间累积显著，且缺乏资源管控；协程池（如 Ants）可稳定资源水位线，需合理选型、设置队列与生命周期管理。
为什么直接用 go 启动协程会出问题
微服务里一来请求就 go handleRequest()，看着简单，但实际压测时容易 OOM 或触发系统级限流。Go 的 goroutine 虽轻量，但每个仍占 2KB+ 栈空间，上万并发时内存和调度开销不可忽视。更麻烦的是，没统一管控时，下游依赖（比如数据库连接池、HTTP 客户端）很容易被瞬间打爆。
协程池不是银弹，但它能把你从“放任自流”拉回可控范围。Ants 是目前最成熟的 Go 协程池库，核心价值不是提速，而是稳住资源水位线。
ants.NewPool 的两种初始化方式怎么选
Ants 提供 ants.NewPool（固定大小）和 ants.NewPoolWithFunc（带任务函数预绑定），选哪个取决于你是否需要复用执行逻辑。
- 用
ants.NewPool(100)：适合任务类型多、参数各异的场景，比如不同业务接口的异步日志写入，每次调用都传匿名函数 - 用
ants.NewPoolWithFunc(100, processJob)：适合单一任务类型，比如统一处理消息队列消费，processJob是你提前定义好的函数，避免闭包逃逸和重复分配
注意：池大小不是越大越好。设为 50～200 之间更稳妥；超过 500 很可能暴露你下游组件的真实瓶颈（比如 DB 连接池只有 32 个）。
提交任务时别忽略 Submit 的返回值
pool.Submit(func()) 返回 error，但很多人直接忽略。这个 error 只在一种情况下出现：池已满且队列也满了（默认队列长度是 0，即不排队）。这意味着你没做背压控制，任务直接丢了。
正确做法：
- 初始化池时显式设置缓冲队列：
ants.NewPool(50, ants.WithNonblocking(false), ants.WithMaxBlockingTasks(1000)) - 提交后检查 error：
if err := pool.Submit(job); err != nil { log.Warn("task dropped", "err", err) } - 更健壮的做法是配合重试或降级（比如写入本地磁盘暂存）
池生命周期管理容易漏掉的点
Ants 池不是创建完就能一直用的。常见疏忽：
- 服务优雅退出时没调用
pool.Release()，导致正在运行的任务被强制中断，数据丢失风险 - 在 HTTP handler 里反复新建池（比如每个请求都
ants.NewPool(10)），既浪费内存又失去复用意义 - 池对象被多个 goroutine 共享没问题，但不要在池释放后再 Submit —— 会 panic 报
"pool is closed"
建议把池作为全局变量或依赖注入，在 main() 初始化，signal.Notify 捕获 SIGTERM 后调用 Release，并等待 pool.WaitFinish() 完成剩余任务。
