先说几个核心判断：直接用 go func(){}() 创建 goroutine 确实简单，但在高频场景下，问题远不止“多开几个协程”那么简单。协程池的核心，其实是控制并发规模、复用运行时上下文，而不是消灭 goroutine 本身。这一点如果没想清楚，后面写出来的池子大概率会出问题。
为什么直接用 go func() {}() 会出问题
高频创建 goroutine 最容易触发的是调度器压力。尤其是在短时突发任务场景，比如 HTTP 请求处理、数据库查询，大量 goroutine 集中创建、退出，会直接导致 runtime.mallocgc 和 runtime.gogo 调用陡增，GC 压力随之上升，P 和 M 的绑定频繁切换。这不是“协程太轻”的问题，而是“无节制复用”破坏了调度平衡。
请记住，协程池不是为了“避免 goroutine”，而是为了控制并发规模，同时复用运行时上下文。关键不在于“池子多大”，而在于“任务入队是否阻塞”，以及“worker 是否真正复用栈空间”。
ants 库的 Submit 为什么比手写 channel 池更稳
很多人习惯用 chan func() 配合 for-select 写一个简易池，但往往漏掉了三个硬伤：worker panic 后退出无人重启、任务函数内 panic 会杀死整个 worker、没有超时控制导致任务卡死拖垮全池。而 ants 在底层做了三件事：panic recover 封装、worker 生命周期自动重建、任务级 context.WithTimeout 支持。
实操上，有几个要点值得注意：
- 用
ants.NewPool(100)初始化时，100 这个数字并不是最大 goroutine 数，而是“常驻 worker 数”；实际并发量仍然受任务排队策略限制 - 提交任务必须用
pool.Submit(func())，不能直接写go f()—— 否则绕过池调度，等于白忙活 - 如果有返回值需求，改用
pool.SubmitWithRecover(func() interface{})，否则 recover 机制不会生效 ants默认不回收空闲 worker，长时间低负载下内存不会下降；可以设置ants.Options{ExpireDuration: time.Second * 30}来缓解
自己实现最小可行池时，sync.Pool 不能用来存 goroutine
有一个常见误解：用 sync.Pool 缓存 func() 或 goroutine 本身。这完全是错的 —— sync.Pool 存储的是对象，而 goroutine 是运行时实体，没法“取出后继续跑”。它更适合缓存 bytes.Buffer、sync.WaitGroup 这类可重置的结构体，而不是执行流。
真正复用的关键在于：让同一个 goroutine 循环从队列中取新任务。正确的模式是：
for { task := <-taskCh task()}在这个模式下，goroutine 的栈被反复使用，调度器不会销毁它（只要它没有被 GC 标记为不可达）。别试图“把 goroutine 放进 pool”，要“让 goroutine 自己活久一点”。
HTTP handler 中误用协程池导致响应延迟升高的典型场景
在 Gin/echo 的 handler 里，有些人会写成：pool.Submit(func() { db.Query(...) })，然后立刻 return。问题在于：handler 返回并不等于请求结束，但 response writer 可能已经被 flush 或关闭。后续 db.Query 的 error 日志或 callback 会写到已关闭的连接，引发 write: broken pipe，同时该 worker 因 panic 被重建，短暂降低吞吐。
安全的做法只有两种：
- 同步执行：handler 内直接调
db.Query，由数据库驱动自身控制连接池，goroutine 池不插手 I/O 层 - 异步且可控：用
pool.SubmitWithRecover，并在任务内显式检查if !ctx.Done() { ... }，配合 handler 的c.Request.Context()
说到底，协程池只适合 CPU-bound 或明确可控生命周期的 blocking-op，比如 JSON 解析、正则匹配、本地缓存计算——这些场景才真正受益于 goroutine 复用。一旦涉及网络 I/O，就必须重新评估责任边界。
