需要Worker Pool是因为直接为每个HTTP请求起goroutine易失控：大量goroutine消耗内存、增加调度开销，还可能打爆下游；Worker Pool通过固定数量协程复用资源，实现并发“可预期、可控制、可监控”，提升吞吐稳定性。
为什么需要Worker Pool而不是直接用goroutine
直接对每个HTTP请求起一个goroutine看似简单，但容易失控：大量并发请求会瞬间创建成千上万个goroutine，消耗过多内存和调度开销，还可能打爆下游服务或触发限流。Worker Pool通过固定数量的工作协程复用资源，让并发“可预期、可控制、可监控”，吞吐量反而更稳更高。
核心结构：任务队列 + 固定Worker + 结果通道
典型Worker Pool由三部分组成：一个输入通道（接收待处理的请求任务）、N个常驻goroutine（从通道取任务并执行HTTP调用）、一个结果通道（统一收集响应或错误）。关键点在于通道要带缓冲（避免阻塞提交），Worker数量需根据CPU核数、IO延迟和目标QPS压测调整，通常从4～16起步。
- 任务结构体建议包含原始请求参数、超时控制、重试次数等字段
- 每个Worker应独立设置
http.Client（含自定义Transport），避免共享连接池竞争 - 务必为每个请求设置
context.WithTimeout，防止单个慢请求拖垮整个Pool
实战代码精简示例
以下是一个轻量可用的Worker Pool骨架（无第三方依赖）：
type Task struct {
URL string
Timeout time.Duration
}
type Result struct {
URL string
Status int
Err error
}
func NewWorkerPool(workers, queueSize int) *WorkerPool {
return &WorkerPool{
tasks: make(chan Task, queueSize),
results: make(chan Result, queueSize),
workers: workers,
}
}
func (wp *WorkerPool) Start() {
for i := 0; i < wp.workers; i++ {
go wp.worker()
}
}
func (wp WorkerPool) worker() {
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 time.Second,
},
}
for task := range wp.tasks {
ctx, cancel := context.WithTimeout(context.Background(), task.Timeout)
req, _ := http.NewRequestWithContext(ctx, "GET", task.URL, nil)
resp, err := client.Do(req)
cancel()
if err != nil {
wp.results <- Result{URL: task.URL, Err: err}
continue
}
resp.Body.Close()
wp.results <- Result{URL: task.URL, Status: resp.StatusCode}
}
}
关键优化点与避坑提醒
真正提升吞吐量的不是加更多worker，而是减少单次请求的瓶颈和干扰：
立即学习“go语言免费学习笔记（深入）”；
- 禁用HTTP/2（如后端不支持）：在
Transport中设ForceAttemptHTTP2: false - DNS缓存复用：用
net.Resolver配合Transport.DialContext做本地缓存，避免每次解析 - 结果消费不要阻塞：用
for range wp.results或另起goroutine处理，别让Worker卡在发送结果上 - 上线前必做压测：用
wrk或hey模拟真实流量，观察worker利用率、平均延迟、失败率拐点
基本上就这些。Worker Pool不是银弹，但它把并发从“野蛮生长”变成“精细耕作”，吞吐量和稳定性才能同步上来。
