ants.Tune() 是唯一合法的运行时容量调整方式，需用读写锁保护且不可并发误用；WithNonblocking(true) 必须配合错误处理与降级策略；NewPoolWithFunc 要求固定函数签名并谨慎类型断言；默认吞掉 panic，须显式设置 WithPanicHandler 才可追溯。
ants.Tune() 动态调容量必须配读写锁保护
池子不能靠重启来扩容，Tune() 是唯一运行时调整 capacity 的合法方式。它内部用 sync.RWMutex 保护容量变量，不是原子操作，所以并发调用 Tune() 不会 panic，但可能被后写覆盖——比如两个 goroutine 同时调 Tune(500) 和 Tune(2000)，最终值取决于执行顺序。
常见误用是把它当信号量用：在 HTTP handler 里每来一个请求就 Tune(runtime.NumCPU()*10)。这会导致频繁 worker 创建/销毁，反而加剧调度压力。
- 只在可观测指标（如队列长度、P99 延迟）持续超标 30s 后才触发一次
Tune() - 调完立刻检查
p.Cap()返回值，确认是否生效（某些版本在池已Release()后调Tune()会静默失败） - 避免在
Submit()闭包内调Tune()，容易和任务执行逻辑耦合，造成死锁风险
WithNonblocking(true) 一开就得配错误处理
默认阻塞模式下，Submit() 在队列满时会挂起 goroutine 等待空闲 worker；设成非阻塞后，它立刻返回 ants.ErrPoolOverload，但很多人只写 _ = pool.Submit(...)，结果任务直接丢弃，连日志都没有。
真实线上场景中，突发流量打进来，非阻塞 + 无错误检查 = 黑盒丢任务。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 必须检查
err：iferr := pool.Submit(task); err != nil { log.Warn("drop task", "err", err) } - 配合降级：比如写入本地磁盘暂存，或发到 Kafka 备份队列
-
WithNonblocking(true)要搭配WithMaxBlockingTasks(n)使用，否则内部 channel 容量为 0，哪怕只提交 1 个任务也可能立即报错
NewPoolWithFunc 避免重复类型断言但要求函数签名固定
用 NewPoolWithFunc(size, fn) 可以省掉每次 Submit() 传闭包的开销，但 fn 必须是 func(interface{}) 类型。这意味着所有参数都得走 interface{}，业务层要自己做类型断言——而断言失败会 panic，且池层 recover 不到这个 panic。
典型翻车点：传了个 map[string]interface{} 进去，断言成 struct{}，程序不崩，但字段全为零值。
- 断言前先用
reflect.TypeOf()或fmt.Sprintf("%v", data)打日志，至少知道传进来的是啥 - 不要在
fn里做耗时操作（如 DB 查询），它复用 worker，阻塞会影响后续任务 -
Invoke()返回 error，但不包含 panic 信息；想捕获 panic，得在fn内部加defer/recover
panic 静默消失不是 bug 是设计，默认行为就是吞掉
ants 默认 recover 了 worker 内 panic，但不做任何输出——这不是疏忽，是为性能妥协。你看到“任务没执行、也没报错、更没日志”，是因为它真就什么都没干。
线上查不到问题根源，八成是漏了 WithPanicHandler。
- 初始化池时必须显式传：
ants.WithPanicHandler(func(p interface{}) { log.Error("ants panic", "value", p) }) - Handler 里别直接
log.Fatal，会 kill 整个池；用log.Error+ 上报监控即可 - 如果任务本身来自用户脚本或插件，建议在
Submit闭包里再套一层defer/recover，双重保险
