动态扩容需显式调用resize()或启用withdynamicadjustment，非自动触发；默认newpool(n)为固定容量池，超载则阻塞；resize()线程安全但仅调整最大worker数，懒启动新goroutine，且受running()和cap()硬约束。
动态扩容不是“开了就自动变大”，而是必须显式调用 Resize() 或启用 WithDynamicAdjustment 才会响应负载变化；默认 NewPool(n) 创建的是固定容量池，超出任务一律阻塞等待。
什么时候该触发 Resize()？看 Free() 和队列积压
ants 本身不自动监控 CPU、延迟或队列长度，所谓“动态”需你自行判断时机。常见可靠信号有：
-
pool.Free()长期为 0，且len(pool.Tasks())（需反射或用带监控的 fork 版本）持续增长 → 说明 worker 全忙、任务在排队，是扩容信号 - 下游耗时突增（如 DB 查询平均从 20ms 升到 200ms），导致单个 worker 处理变慢 → 同样表现为
Free()趋近于 0，此时扩容比加机器更及时 - 业务有明确波峰（如每小时整点报表生成），可提前
pool.Resize(200)，峰值过后再缩回pool.Resize(50)
注意：Resize() 是线程安全的，但仅调整“最大允许 worker 数”，不会立刻起新 goroutine；新 worker 在下一次任务提交且无空闲时才懒启动。
Resize() 的行为边界：不能无限扩，也不能低于当前运行数
pool.Resize(n) 实际生效受两个硬约束：
- 若
n （当前正在干活的 goroutine 数），调用会成功但实际容量不变，直到有 worker 自然退出（比如任务结束、空闲超时）才会逐步缩容 - 若
n > pool.Cap()且你没传ants.WithDynamicAdjustment(true)，Resize()仍有效，但池不会主动回收超出原Cap()的空闲 worker —— 它们会一直待命，直到你再次Resize()缩小或调用Release() - 频繁调用
Resize()（如每秒多次）会导致调度抖动，建议加简单限频，例如用time.Since(lastResize) > 10 * time.Second
WithDynamicAdjustment(true) 真正的自动扩容逻辑
这个选项开启后，ants 会在每次任务入队前检查 Free() == 0 && len(queue) > threshold，满足则尝试扩容。但注意：
- threshold 默认是 100，即队列积压超 100 个任务才触发；可通过
ants.WithQueueSize(50)调低 - 扩容步长固定为原
Cap()的 25%，比如原池大小 100，第一次扩到 125，再积压又扩到 156 —— 不是线性+10，也不是翻倍 - 它只扩容，不自动缩容；缩容仍需你手动
Resize()或依赖WithExpiryDuration()清理空闲 worker - 高 QPS 场景下，这个自动检查本身有微小开销，压测时建议对比开关前后的
schedlat（调度延迟）指标
别忽略 panic 恢复对扩容判断的干扰
一个常被忽视的问题：Submit() 内部 panic 会被 ants 默认 recover，worker 不退出，但任务逻辑实际失败。如果大量任务因 panic 卡住（比如反复重试失败的 HTTP 请求），Free() 仍显示正常，而真实吞吐已崩 —— 此时扩容毫无意义，反而掩盖了根本问题。
务必做两件事：
- 用
ants.WithPanicHandler()接管 panic 日志，至少输出panic值和堆栈 - 监控
pool.Running()+ 业务成功率，而非只盯Free()；Running 长期高位但成功率跌穿阈值，优先查错误而非扩池
真正决定要不要扩容的，从来不是“有多少 goroutine 在跑”，而是“有多少任务在正确完成”。
