go语言动态worker本质是用channel控制goroutine活跃状态而非实时启停；频繁创建销毁反而降低吞吐，因栈内存开销、gc压力、调度器负担及下游qps瓶颈。
Go 语言里没有“动态 worker”的内置类型，所谓动态扩缩容，本质是用 channel 控制已有 goroutine 的活跃状态，而非实时启停——频繁创建/销毁 goroutine 反而拖慢吞吐。
为什么直接 go func() 会压垮吞吐
每个 goroutine 至少占 2KB 栈内存，瞬间拉起上千个，GC 压力陡增；调度器要管理海量 G，runtime.schedule() 开销上升；更关键的是，下游服务（比如 DB、HTTP 接口）有真实 QPS 上限，你并发开得再猛，任务也卡在 channel 缓冲区或超时失败，实际吞吐不升反降。
- 典型现象：
runtime: goroutine stack exceeds 1GB limit或 GC pause 超过 50ms - 真实瓶颈常不在 CPU，而在任务积压延迟：入队到出队平均耗时 >200ms 就该扩容
- 固定池（如 8 个 worker）跑 100QPS 没问题，但跑突发 500QPS 时，
len(jobs)持续 >100，说明池子已饱和
ants 库的 SetSize() 不是热更新，别被名字骗了
github.com/panjf2000/ants 的 SetSize() 方法只是原子更新内部 cap 字段，并不会立刻启停 worker；它只影响后续的扩容决策和新 worker 的准入上限。老 worker 仍按原逻辑运行，也不会自动退出。
- 调用
pool.SetSize(50)后，若当前只有 10 个活跃 worker，不会自动拉起 40 个 - 它真正生效的场景是：当积压触发扩容逻辑时，新 worker 数量上限从旧值变成 50
- 缩容必须靠空闲检测+主动 quit 信号，
SetSize()本身不发任何信号
自己实现扩缩容，关键看三个 channel 状态
核心不是“有多少 goroutine”，而是“有多少能立刻接活”。需同时监听：jobs（任务队列长度）、ready（空闲 worker 列表）、quitCh（缩容指令）。主控协程每 5 秒检查一次：
- 扩容条件：
len(jobs) > 2 * active && active → 调用 <code>spawnWorker() - 缩容条件：
len(ready) == active && active > minWorkers && idleTime > 10s→ 向最老 worker 的quitCh发信号 - worker 内部必须用
select处理quitCh，且只在当前任务完成后退出，不能中断执行
吞吐最大化的两个隐藏细节
很多人调大 maxWorkers 就以为吞吐上去了，其实卡点常在缓冲区和锁竞争上：
- 任务 channel 缓冲区别设太大：
jobs := make(chan Job, 1000)容易掩盖积压，导致扩容滞后；建议设为minWorkers * 2起步 - 共享状态读写尽量用
atomic.Int64，别用sync.Mutex包裹active++这种高频操作，否则扩缩逻辑本身成瓶颈 - worker 退出前要
pool.wg.Done()，主控用pool.wg.Wait()等待所有 worker 彻底退出，否则close(pool.jobs)可能 panic
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
