Go worker并发需依负载类型动态设定数量：CPU密集型设为runtime.NumCPU()，I/O密集型为NumCPU()2~50，混合型从NumCPU()3起步；任务channel必须带缓冲并合理限容，满时应拒绝或丢弃任务。
Go 语言里 worker 并发不是靠“开越多越好”，而是靠任务池 + 动态伸缩 + 负载感知来维持高吞吐。盲目 go f() 几百次，大概率触发 goroutine 泄漏或调度器过载，CPU 拉满但 QPS 不升反降。
worker 数量不能硬编码，得看 CPU 和 I/O 特性
固定写死 runtime.GOMAXPROCS(8) 或启动 50 个 worker，对吞吐没帮助，反而可能拖慢响应。关键在匹配实际负载类型：
- CPU 密集型任务（如图像压缩、加解密）：worker 数量建议设为
runtime.NumCPU()，再多会引发频繁上下文切换 - I/O 密集型任务（如 HTTP 调用、DB 查询）：可设为
runtime.NumCPU() * 2到50之间，留出等待间隙让其他 goroutine 运行 - 混合型服务建议从
runtime.NumCPU() * 3起步，再用pprof观察goroutine阻塞分布和scheduler抢占延迟
任务 channel 必须带缓冲，否则生产者容易卡死
无缓冲 chan Task 要求生产者和消费者严格同步，一旦某个 worker 处理变慢（比如 DB 延迟升高），整个任务入队就会阻塞，上游请求直接超时。带缓冲是解耦的关键：
- 缓冲大小不是越大越好：
jobs := make(chan Task, 100)是常见起点，但需结合平均处理耗时和峰值 QPS 估算；例如平均 100ms/任务、峰值 500 QPS，则缓冲至少要撑住 50 个待处理任务 - 缓冲区填满后，应拒绝新任务（返回 429）或丢弃低优先级任务，而不是让生产者无限等待
- 避免在
select中只写case jobs —— 必须加 <code>default:或timeout分支，防止 goroutine 卡在发送上
单个任务必须自带 context timeout，不能依赖全局超时
HTTP handler 层的 context.WithTimeout(r.Context(), 5*time.Second) 只控制请求生命周期，不保证任务内部调用（比如第三方 API、DB 查询）及时退出。一个慢任务卡住 worker，会导致后续所有任务积压：
立即学习“go语言免费学习笔记（深入）”；
- 任务入队前就封装好带 deadline 的 context：
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)，然后把ctx和cancel一并传入任务结构体 - worker 内部在每个可能阻塞的操作前检查：
select { case ，尤其在 <code>http.Do、db.QueryRow、ch 前 - 不要在 goroutine 里重复调用
context.WithTimeout—— 每次都会新建 timer，累积大量 goroutine 和 heap 对象
动态伸缩 worker 数量比静态池更稳，但得有依据
流量突增时，等运维手动扩容已来不及；盲目自动扩到 200 个 worker，又可能压垮下游服务。真正有效的动态调整，依赖两个信号：
- channel 缓冲区使用率持续 >80%（比如
len(jobs)/cap(jobs) > 0.8），说明消费跟不上，可临时 +1～2 个 worker（上限建议设为初始值 ×2） - worker 平均空闲时间 runtime.ReadMemStats 显示 GC 频次上升，说明 worker 过剩，可逐步停掉空闲超 30s 的 goroutine（用
sync.WaitGroup+ 标志位控制退出） - 注意：伸缩操作本身要加锁或用原子计数，避免并发修改导致 worker 数抖动；更稳妥的做法是用
errgroup.Group替代裸sync.WaitGroup，它天然支持 cancel 传播和错误聚合
最常被忽略的一点：worker 池的“动态”不是指数量能变，而是指它能感知自身瓶颈并做出反馈——比如把积压任务数、平均延迟、失败率这些指标暴露给 metrics 系统，再由外部控制器决定是否扩缩容。纯代码层的自动伸缩容易误判，尤其在短时脉冲流量下。
