Worker Pool 通过控流、复用和解耦提升吞吐量：固定 worker 数量避免 goroutine 泛滥，任务提交与执行分离实现快速响应，带缓冲 channel 支持背压感知；需合理配置 worker 数（CPU 型≈核数，IO 型2~5倍）、缓冲大小（略超峰值），并防范 panic、超时、竞态等稳定性陷阱。
为什么 Worker Pool 能提升吞吐量？
直接起一堆 goroutine 处理请求，看似并发高，实则容易因调度开销、内存暴涨、锁争用或系统资源耗尽反拖慢整体性能。Worker Pool 的核心价值不是“多开协程”，而是“控流 + 复用 + 解耦”：固定数量的 worker 持续从任务队列消费，避免瞬时 goroutine 泛滥；任务提交与执行分离，让生产者（如 HTTP handler）快速返回；channel 作为缓冲和协调媒介，天然支持背压感知。
如何正确实现带缓冲的任务分发？
常见错误是把 jobs channel 设为无缓冲，导致 dispatcher 在提交任务时频繁阻塞——尤其当 worker 短暂繁忙，整个上游就卡住。正确做法是给 channel 加合理缓冲：
-
jobs := make(chan Job, 100)：缓冲大小应略大于典型峰值任务数，例如每秒接收 80 个请求，处理平均耗时 100ms，则 10~20 已够；设 100 是为应对短时毛刺，而非盲目堆大 - 必须在所有任务提交完毕后调用
close(jobs)，否则每个 worker 的for job := range jobs永不退出，造成 goroutine 泄漏 - 若任务携带数据（如结构体），避免在 channel 中传递大对象；优先传指针或 ID，由 worker 按需加载
worker 数量和缓冲大小怎么配？
这不是拍脑袋定的参数，而要匹配实际负载特征：
- CPU 密集型任务：worker 数建议 ≈
runtime.GOMAXPROCS(0)（即逻辑 CPU 核数），再多只会增加调度切换，不提效 - I/O 密集型任务（如调外部 API、DB 查询）：可设为 2~5 倍核数，因为大量时间在等待，但上限建议 ≤ 100，防止连接池打满或上下文切换反成瓶颈
- 缓冲大小 ≠ worker 数：比如 5 个 worker 配 200 容量的
jobschannel，是为了吸收突发流量，不让生产者等；但若消费者长期跟不上，buffer 满了仍会阻塞，此时该优化的是 worker 处理逻辑，而非继续加 buffer
容易被忽略的稳定性陷阱
很多线上事故源于 Worker Pool 的“半成品”实现：
立即学习“go语言免费学习笔记（深入）”；
- 没加
recover()：worker 内部 panic 会导致该 goroutine 消失，任务静默丢失，且无法被监控捕获 - 结果 channel 不带缓冲或未关闭：若用
results := make(chan Result)（无缓冲），且主流程未及时接收，worker 发送结果时就会卡死 - context 超时未透传：worker 执行的子操作（如 DB 查询、HTTP 调用）若没继承
ctx，可能永远 hang 住，拖垮整个 pool - 误复用非线程安全对象：比如在多个 worker 里共用一个未加锁的
map或sql.Tx，引发 panic 或数据错乱
真正稳定的 Worker Pool，从来不是写完就能上线，而是每一处阻塞点、panic 点、超时点都经过压测和日志验证——尤其是 buffer 满、worker panic、context cancel 这三种状态，必须有明确可观测行为。
