ants支持运行时动态调整池大小，但需调用resize()而非直接修改；其行为是控制新worker启停节奏，不中断运行中任务，而原生channel+waitgroup等多数轻量库因缺乏状态机封装，不支持安全resize。
ants 支持运行时动态调整池大小，但不是所有库都支持
直接结论：用 ants 可以调用 Resize() 方法实时增减 worker 数量；而原生 channel + sync.WaitGroup 实现的池、或 pond 等多数轻量库，**不支持动态 resize**——它们在初始化后固定 worker 数，强行改会导致竞态或逻辑错乱。
根本原因在于：worker 是长期存活的 goroutine，它们持续从 channel 读任务。如果中途增删 goroutine，需同步修改 channel 关闭逻辑、WaitGroup 计数、甚至任务分发策略，极易出错。所以真正支持动态伸缩的库，底层必须封装状态机和原子计数器，而非简单起一堆 goroutine。
ants.Resize() 的实际行为和限制
ants 的 Resize() 不是“立即生效”的魔法操作，它控制的是**后续新 worker 的启停节奏**：
- 若当前活跃 worker 数 ants.WithMaxBlockingTasks 等参数影响）
- 若当前活跃 worker 数 > 目标值，不会强制杀掉正在跑任务的 worker，而是等它们空闲后自动退出（配合空闲超时）
- resize 过程中，已有任务不受影响，排队任务仍正常分发
示例：
p, _ := ants.NewPoolWithFunc(5, func(i interface{}) {
time.Sleep(time.Second)
})
// 5 个 worker 正在运行
p.Resize(12) // 下次有新任务且无空闲 worker 时，可能启动第 6~12 个
p.Resize(3) // 已在跑的 5 个不会被中断，但空闲后只保留 3 个常驻
为什么别自己手写动态 resize 逻辑
常见翻车点：
- 用
close(taskChan)再重开 channel —— 已阻塞在的 goroutine 会 panic - 并发修改
sync.WaitGroup计数 —— 导致Wait()永不返回或提前返回 - 未处理 worker 中的 panic 恢复 —— 一个 panic 就让整个池少一个 worker，最终缩到 0
- 忽略上下文取消 —— resize 后旧 worker 仍持有过期 context，无法响应服务关闭
哪怕加了锁保护计数器，也很难覆盖所有边界：比如 resize 到 0 时，是否允许排队任务继续？是否要拒绝新提交？这些语义必须由库统一定义，而不是靠业务代码临时补丁。
替代方案：用信号量 + 空闲检测模拟“逻辑伸缩”
如果你不用第三方库，又确实需要负载感知能力，推荐用 semaphore + 定时检测，绕过“修改 worker 数”这个高危操作：
- 固定一组长期运行的 worker（例如 CPU 核心数）
- 用
golang.org/x/sync/semaphore控制并发上限，根据 QPS 或队列长度动态调Acquire()的权值 - 另起 goroutine 定期检查空闲时间，超过阈值就调
Release()并标记该 worker 可回收（实际只是不再分发新任务）
这本质上不是“调整池大小”，而是把并发控制权从 worker 数转移到信号量上——更轻量、更安全，也符合 Go “控制并发度而非预分配 goroutine” 的设计哲学。
真正难的不是让数字变大变小，而是让变化过程对任务无感、对监控可观测、对错误可恢复。这点上，ants 做了足够多的防御性封装，自己造轮子前，先确认是否真需要脱离它的抽象层。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
