ants.newpool初始化必须配withexpiryduration和withnonblocking：默认不回收空闲worker且任务队列无缓冲，易致内存泄漏或静默拒绝；需显式设expiryduration控制回收、nonblocking决定阻塞或丢弃策略，并配panichandler防panic静默。
ants.NewPool 初始化必须配 expiry 和 nonblocking
直接 ants.NewPool(100) 在生产环境几乎必出问题：默认不回收空闲 goroutine，跑几天后池里 worker 数只增不减；且任务队列无缓冲，提交超载任务立即返回 ants.ErrPoolOverload，而不是排队等待。
- 务必显式传
ants.WithExpiryDuration(30 * time.Second)，让空闲超过 30 秒的 worker 主动退出 - 用
ants.WithNonblocking(false)启用阻塞式提交——任务会排队，而非直接拒绝 - 若需降级能力，可配合
ants.WithDelegationStrategy()自定义拒绝时的 fallback 行为
pool.Submit() 的 panic 不会透出，但也不自动打印日志
pool.Submit(func() { riskyOp() }) 中的 panic 会被 ants 内部 recover，但不会 log 到 stderr 或 stdout。线上服务看不到错误，只表现为任务静默失败。
- 必须手动设置
ants.WithPanicHandler(func(p interface{}) { log.Printf("worker panic: %v", p) }) - 不要依赖 defer recover() 包在任务闭包里——ants 已做这层封装，重复 recover 反而掩盖真实调用栈
- panic 日志建议带上 task ID 或 traceID，否则无法关联请求上下文
Release() 必须调用，且不能晚于所有 Submit 完成
pool.Release() 关闭池并等待所有 worker 退出。如果在还有任务正在执行时调用，会导致部分任务被丢弃或卡死；如果从不调用，则 worker goroutine 永不退出，进程内存持续上涨。
- 推荐在 defer 中调用，但要确保 defer 位置在所有 Submit 循环之后（比如放在 for 循环外层）
- 若 Submit 是异步触发（如 HTTP handler 中），需用
sync.WaitGroup或context.WithCancel确保任务全部进入池后再 Release - Release 后再 Submit 会 panic，错误信息是
"submit task to a closed pool"，不是 nil error
手写 channel 池时，jobs chan 容量和关闭顺序是致命细节
不用 ants 时，常见手写方案用 jobs := make(chan func(), N) + 固定 worker 数。但多数人栽在两个地方：channel 缓冲区设太小导致 Submit 阻塞；或关闭池时先 close jobs 再 wg.Wait，却没处理好 worker 正在读取的 race。
-
jobs容量建议 ≥ 池大小 × 2，避免瞬时高峰写满后调用方 goroutine 卡住 - 关闭流程必须是：① close(jobs) → ② wg.Wait() → ③ 不再往 jobs 写入
- worker 循环必须用
for f := range jobs，不能用select { case f := ，否则关 channel 后循环不会自动退出
协程池不是万能开关，它只对 IO 密集、可排队、生命周期短的任务有效；CPU 密集型任务池化反而增加调度开销，该上 runtime.GOMAXPROCS 调优就别硬套池。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
