ants.NewPool 默认阻塞式提交，瞬时高频请求会导致 Submit 卡死；不配 WithNonblocking 和 WithPanicHandler 会隐藏 panic 与任务积压；需显式处理超时、panic 及 goroutine 泄漏。
直接用 ants.NewPool 无法扛住瞬时高频请求，不配 ants.WithNonblocking(true) 和 ants.WithPanicHandler 就上线，等于把 panic 和任务积压藏进黑盒。
瞬时请求洪峰下 Submit 为什么会卡死
默认 ants.NewPool(n) 是阻塞式提交：池满后新任务会永久等待空闲 worker。比如你设了 size=10，但每秒涌进 500 个任务，第 11 个开始就堵在 pool.Submit() 调用里——不是慢，是彻底挂起，整个 goroutine 卡住不动。
- 这不是 bug，是设计行为：ants 默认优先保任务不丢，而非保响应不超时
- HTTP 服务里这种卡顿会直接拖垮连接池、耗尽
net/http.Server的 idle timeout，引发级联超时 -
Submit返回error只在池关闭或非阻塞模式队列满时触发，阻塞模式下它根本不返回，也就没法做 fallback 或降级
panic 静默消失比崩溃更危险
协程池里跑的任务一旦 panic，ants 默认只 recover 不打日志——你既看不到错误，也收不到通知，任务就“凭空消失”了。线上查问题时只会看到：指标断崖下跌、日志无异常、监控无报错。
- 必须显式传
ants.WithPanicHandler(func(p interface{}) { log.Printf("ants panic: %v", p) }) - 或者每个
Submit闭包里自己加defer func() { if r := recover(); r != nil { log.Printf("task panic: %v", r) } }() - 特别注意：第三方 SDK、反射调用、用户输入脚本等不可信代码，必须靠池层 recover 拦截，上层 try-catch 无效
语言学习资源管理要避免 Goroutine 泄漏
语言学习类服务常有长周期任务（如音频转写、语法分析、词频统计），若每个请求都 go func() 启动，极易泄漏：goroutine 执行完没释放、channel 写入未被读、context 超时未传播。
立即学习“go语言免费学习笔记（深入）”；
- 用
ants.NewPoolWithFunc(n, fn)更安全：统一入口函数 + 类型断言，避免闭包捕获变量地址导致的逻辑错乱 - 任务参数别直接传指针或全局 map；需要共享状态时，用
sync.Pool或带缓冲 channel 传递，而不是让所有 worker 并发写同一 slice - 调用
pool.Release()后别再Submit，否则会 panic；想等任务全结束再退出，得配pool.Wait()（仅NewPoolWithFunc支持）
最易被忽略的是：池 size 不是“建议值”，而是硬上限；非阻塞模式下 Submit 返回 error 时，你得立刻决定是丢弃、重试还是降级——这一步没兜底逻辑，流量洪峰就变成雪崩起点。
