直接用 go func(){}() 易拖垮服务，因每goroutine至少占2KB栈空间且调度有开销，高并发时内存暴涨、GC压力大、OOM风险高；sync.Pool不适用于Worker Pool，因其无任务队列、限流、超时等能力；应使用带缓冲channel+固定worker数的方案，并补全context控制、结果回调与拒绝策略。
为什么直接用 go func() {}() 容易把服务拖垮
协程（goroutine）虽轻量，但不是免费的。每启动一个，至少占用 2KB 栈空间，调度器也要维护其状态。高并发场景下无节制地 go doWork()，会瞬间创建成千上万个协程，导致内存暴涨、GC 压力陡增、甚至被系统 OOM kill。
典型现象：接口响应延迟突增、runtime: out of memory 报错、pprof 显示 goroutine 数量持续 >10k 且不下降。
- 别指望 GC 能及时回收“已执行完”的协程——它们可能还在 runtime 的等待队列里
- 协程不是线程，但调度开销真实存在；大量 goroutine 争抢 M/P 会导致上下文切换变多
- 没有池控，错误处理也容易丢失：panic 未 recover 会直接终止整个 goroutine，但没人知道它属于哪次请求
sync.Pool 不适合做 Worker Pool
sync.Pool 是为临时对象复用设计的（比如 []byte 缓冲区），不是用来管理长期存活的工作协程。它不保证对象一定被复用，也不提供排队、限流、超时等能力。
常见误用：把 worker 函数塞进 sync.Pool，以为能“复用协程”——其实只是复用了函数闭包或结构体，goroutine 本身每次仍是新启的。
立即学习“go语言免费学习笔记（深入）”；
-
sync.Pool.Get()返回的是任意上次存入的对象，无法控制“谁来执行任务” - 没有任务队列，无法实现“提交任务 → 等待执行完成”语义
- 生命周期不可控：Pool 中对象可能被 GC 清理，导致 worker 意外消失
用带缓冲 channel + 固定数量 for-select 实现最小可用 Worker Pool
核心思路：启动固定数量的长期运行协程（worker），通过 channel 接收任务；任务提交方只往 channel 发送，不关心谁执行、何时执行。
关键不是“池有多 fancy”，而是“有没有硬限流 + 任务不丢 + 错误可捕获”。
type Job struct{ ID int; Payload string }
type Result struct{ ID int; Err error }
<p>func NewWorkerPool(workers, queueLen int) *WorkerPool {
jobs := make(chan Job, queueLen)
results := make(chan Result, queueLen)</p><pre class='brush:php;toolbar:false;'>for i := 0; i < workers; i++ {
go func() {
for job := range jobs {
// 实际处理逻辑
err := process(job.Payload)
results <- Result{ID: job.ID, Err: err}
}
}()
}
return &WorkerPool{jobs: jobs, results: results}}
- 缓冲 channel 长度决定最大积压任务数；超过则
jobs <- job会阻塞或超时，天然限流 - worker 数量即并发上限，与 QPS/耗时强相关：比如平均处理 100ms，要撑住 100 QPS，至少需 10 个 worker
- 务必在 worker 内部 recover panic，否则单个 panic 会让整个 worker 退出，池容量悄悄缩水
- 不要在 worker 中直接写日志或调外部 API——这些操作应封装进
process()，便于 mock 和监控
什么时候该加 context 控制、结果回调和拒绝策略
基础版能跑，但生产环境必须补三块：超时取消、结果通知、过载拒绝。否则用户请求卡死、监控失焦、故障扩散。
例如 HTTP handler 提交任务后，不能干等 channel，必须支持 ctx.Done() 退出；也不能让失败任务沉默消失，得有明确 Result 反馈。
- 任务 channel 改用
chan *Job，把context.Context和回调函数作为*Job字段传入 - worker 中用
select { case 实现可取消 - 拒绝策略不是简单
return：要返回特定错误（如ErrPoolFull），并记录 metric（比如worker_pool_reject_total） - 避免在 worker 里调
job.Callback()——如果回调很慢，会堵住整个 worker；应另起 goroutine 或投递到另一 channel
最常被忽略的一点：worker pool 的初始化和关闭不是一次性的。服务 reload、配置热更新时，旧 pool 必须能 graceful shutdown，包括 drain 未处理任务、等待正在执行的任务结束——这部分逻辑比启动更难测、更容易漏。
