ants.NewPool需配WithPanicHandler防panic静默；size固定不扩容，超量任务阻塞；高并发需WithNonblocking(true)；Submit无内置timeout，需context封装；NewPoolWithFunc适合固定任务但需手动类型断言；闭包勿直接捕获循环变量。
直接用 ants.NewPool 就能跑起来，但不配 ants.WithPanicHandler 或自己 recover，panic 会静默消失——这是线上最常踩的坑。
创建池时必须指定 size，且默认不自动扩容
ants 不是“弹性伸缩池”，NewPool(10) 就死卡在 10 个并发，超出任务会阻塞等待空闲 worker。这点和很多人直觉相反，以为它像线程池一样能动态扩缩。
- 如果任务突发量大、延迟敏感，得主动加
ants.WithNonblocking(true)，否则Submit会永久阻塞（比如 channel 满了又没消费者） - 想让池子支持超时提交，得组合
context.WithTimeout自己封装一层，ants 本身不提供 Submit-level timeout -
NewPoolWithFunc更适合固定模式任务（如统一处理 HTTP 请求），避免每次传闭包；但注意传入的函数签名必须是func(interface{})，参数要自己类型断言
Submit 闭包里别直接捕获循环变量
常见写法 for i := 0; i 会导致所有任务都打印最后一个 i 值——Go 闭包捕获的是变量地址，不是值。
- 必须显式复制：
idx := i; pool.Submit(func() { fmt.Println(idx) }) - 如果任务需要共享状态（如写 slice），记得加
sync.WaitGroup或 channel 同步，Submit是纯异步调用，不等任务结束就返回 - 错误检查不能省：
err := pool.Submit(...)返回ants.ErrPoolClosed或ants.ErrPoolOverload，尤其在Release()后继续 Submit 会 panic
panic 不会崩程序，但也不会打日志——除非你手动配
默认行为是 recover 后直接吞掉 panic，连 stack trace 都不输出。线上出问题时你会看到“任务没执行、也没报错、更没日志”，然后开始怀疑人生。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须初始化时传
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) } }() - 特别注意：当任务来自用户输入（比如插件脚本）、或调用不可信第三方库时，池层的 recover 是最后一道防线，别依赖上层兜底
Release 不等于立刻停所有 worker，得配合 Wait
pool.Release() 只是标记池关闭并关掉内部 channel，正在运行的任务仍会跑完，但新任务会被拒绝。如果你没等它们结束就退出 main，部分任务可能被截断。
- 想等全部完成再退出，得调
pool.Wait()（仅对NewPoolWithFunc有效）或自己用sync.WaitGroup计数 -
Release()后再调Submit会返回ants.ErrPoolClosed，但不会 panic；而反复调Release()本身是安全的（有 once 控制） - 测试时容易忽略：worker 内部的
time.Sleep或网络 IO 可能远长于主流程，不 wait 就 exit，结果就是“看着程序结束了，其实还有 goroutine 在后台跑”
真正难的从来不是怎么起一个池，而是搞清谁该负责 recover、谁该管超时、谁来决定任务失败后重试还是丢弃——这些逻辑一旦混在 Submit 闭包里，池子就从节流工具变成隐藏状态泄漏源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
