ants.NewPool 默认创建固定容量线程池，不自动扩容；需显式启用 ants.WithDynamicAdjustment(true)（v2.8.0+）并配合 WithNonblocking(true) 避免阻塞，支持运行时 Tune/Resize 调整，但需监控排队、panic 等指标。
ants.NewPool 默认不支持动态扩容
直接调用 ants.NewPool(10) 创建的池是固定容量的，不会随任务压力自动增加 worker 数量。这不是 bug，是设计选择：它更接近 Java 的 newFixedThreadPool，而非 newCachedThreadPool。很多线上服务误以为“高并发库=自动伸缩”，结果突发流量时任务在队列里堆积、延迟飙升，却查不到扩容日志——因为根本没发生扩容。
如果你需要动态行为，必须显式启用：ants.WithDynamicAdjustment(true)（注意：该选项仅在 ants/v2 且版本 ≥ v2.8.0 后可用）。老版本或未传此选项时，Cap() 和 Running() 始终稳定，别指望它涨。
- 启用后，池会根据
Free() == 0持续时间（默认 5 秒）和当前负载，按步进策略扩容，上限为初始size × 2（可配WithMaxWorkers(n)） - 缩容触发条件是空闲超时（默认 60 秒）+ 当前
Running() - 扩容/缩容过程非原子：新 worker 启动期间，旧 worker 仍在处理任务；缩容只拒绝新任务，不中断运行中任务
Submit 阻塞 vs Nonblocking：扩容前先保命
即使开了 WithDynamicAdjustment(true)，默认 Submit() 仍会阻塞——扩容需要时间，而你等不起。尤其在 HTTP handler 中，一个阻塞的 Submit() 可能拖垮整个连接超时。
必须搭配 ants.WithNonblocking(true) 使用：
-
Submit()立即返回ants.ErrPoolOverload，而不是卡住 - 此时你才有机会做降级：写入本地队列、丢弃低优先级任务、或 fallback 到
go func()（慎用，需限流） - 注意：
WithNonblocking(true)和WithDynamicAdjustment(true)可共存，但前者解决“现在能不能提交”，后者解决“之后能不能撑住”
如何安全地手动扩容与缩容
动态调整不是银弹。某些场景下你更需要精确控制，比如按 CPU 使用率或请求 P95 延迟触发扩缩容。ants 提供了运行时干预接口：
-
pool.Tune(newSize int)：同步修改当前容量上限（注意不是立刻启停 worker，而是影响后续调度） -
pool.Resize(newSize int)：异步调整实际 worker 数，会启动/停止 goroutine，返回error（如ants.ErrPoolClosed） - 调用
Resize()后务必检查Free()和Running()，避免误判空闲状态 - 不要在
Submit()闭包内调用Resize()—— 可能引发竞态，应在独立 goroutine 或监控循环中执行
容易被忽略的监控盲区
很多人只看 Running() 和 Free()，但这两个值掩盖了关键问题：
-
Running()包含正在执行 + 正在 GC + 正在阻塞 IO 的 goroutine，无法区分是否真在干活 - 没有内置队列长度指标：任务在 channel 缓冲区里积压多少？得自己 wrap
Submit()记录失败/排队耗时 -
WithPanicHandler必须配，否则 panic 任务静默失败，Running()还显示“正常”，但业务逻辑已断 - 扩容后若任务仍慢，大概率是任务本身有锁竞争或 DB 连接池瓶颈，不是协程不够——别无脑调大
Cap()
真正要盯的是：提交成功率、平均排队时长、panic 频次、以及扩容/缩容事件日志。这些不靠 ants 自带 API，得你补一层薄胶水代码。
