ants池设100卡住主因是未配置任务队列上限与超时策略：默认阻塞式池在worker全忙时，第101个submit()会永久阻塞调用方；须配ants.withmaxblockingtasks(500～2000)或withnonblocking(true)防拖垮。
为什么ants池大小设成100就卡住？
不是池太小，是没配对任务队列和超时策略。默认NewPool(100)创建的是阻塞式池，当100个worker全忙、且任务队列未显式限制时，第101个Submit()会一直阻塞调用方——这在HTTP handler里等于把整个请求协程挂起，P99延迟直接跳到秒级。
- 必须加
ants.WithMaxBlockingTasks(n)，n建议设为500～2000，避免无限排队拖垮内存 - IO密集型服务（如DB查询、RPC）可设更高；CPU密集型建议≤500
- 若业务允许丢弃，直接开
ants.WithNonblocking(true)，失败时Submit()返回ErrPoolOverload，由上层做降级或重试
IdleTimeout和ExpiryDuration到底该设多少？
IdleTimeout是http.Server的参数，ExpiryDuration才是ants池的worker空闲回收时间——这两个常被混用，但作用对象完全不同。
-
ants.WithExpiryDuration(30 * time.Second)：worker空闲30秒后自动销毁，适合突发流量后快速缩容，防止长驻goroutine吃内存 -
http.Server.IdleTimeout：控制TCP连接空闲多久断开，和ants无关，但两者要协同——比如设成相同值（30s），避免连接还活着但worker已回收，导致新请求进来时临时扩容来不及 - 别设
ExpiryDuration = 0：那等于禁用过期清理，worker只增不减，压测后runtime.NumGoroutine()会持续上涨
WithPreAlloc=true真能提速？什么场景下反而更慢？
预分配是让ants启动时就创建好全部worker，省去运行时动态扩缩容的锁竞争，但代价是启动慢、初始内存占用高。
- 适用场景：服务启动后QPS稳定在高位（如网关、消息消费者），且能接受100ms级冷启动延迟
- 反模式：CLI工具、短命Job、QPS波动剧烈的服务——预分配的worker很快闲置，又无法及时回收，
pool.Free()长期接近0，反而浪费资源 - 验证方法：压测时对比
pool.Running()和pool.Free()曲线，如果Free长期＞80%且无明显波峰，说明预分配过度
动态Tune()调参时最危险的操作
用p.Tune(2000)扩容看着很爽，但如果没同步调整WithMaxBlockingTasks，可能瞬间把等待队列从500拉到2000，内存占用翻倍；更糟的是，如果旧worker正在处理超时任务，Tune()不会中断它们，新容量只是“纸上谈兵”。
- Tune前务必确认：当前
pool.Running() - 缩容（如
p.Tune(500)）时，ants只会等worker自然退出，不会强制kill——所以缩容后要配合context.WithTimeout确保任务本身有超时，否则worker卡死会导致实际并发数远低于预期 - 高频Tune（如每秒调一次）会引发锁竞争，实测在8核机器上超过5次/秒，
pool.Submit()延迟毛刺明显上升
真正难调的不是数字，而是worker生命周期和业务逻辑超时的咬合点：一个DB查询设了5s超时，但ExpiryDuration只设了2s，结果worker刚销毁，查询还在OS TCP栈里跑着——这种隐性资源残留，比参数设错更难排查。
