典型表现为pprof中goroutine数持续上涨或程序退出卡住，根本原因是worker未在select中监听ctx.Done()或未处理已接收任务；正确模式是select同时等待任务通道和ctx.Done()。
worker pool 关闭时 goroutine 泄露的典型表现
运行一段时间后 pprof 显示 goroutine 数持续上涨，或程序退出前卡住不返回——这基本是 worker 未响应取消信号、仍在阻塞读取任务队列导致的。根本原因不是没调 cancel()，而是 worker 没在 select 中监听 ctx.Done()，或者监听了但没处理已接收但未完成的任务。
必须在 select 中同时监听 ctx.Done() 和任务通道
worker 的核心循环不能只等任务，否则 context.Context 取消后它还在空转。正确模式是用 select 同时等待两件事：
- 从任务通道接收新任务（
job := ） - 响应上下文取消（
case ），此时要立刻退出循环
示例片段：
for {
select {
case job, ok := <-jobs:
if !ok {
return
}
handle(job)
case <-ctx.Done():
return // 立即退出，不处理后续任务
}
}
注意：如果 handle(job) 是耗时操作，且你希望它执行完再退出，那得换策略——见下一条。
立即学习“go语言免费学习笔记（深入）”；
需要“优雅等待正在执行的任务完成”时的处理要点
若业务要求已领取的任务必须做完，就不能在 case 后直接 return。此时需配合 <code>sync.WaitGroup 跟踪活跃 worker，并在主流程中先关闭任务通道、再等待所有 worker 归还。
- worker 启动前
wg.Add(1)，退出前wg.Done() - 主流程调用
close(jobs)（而非只调cancel()），让已阻塞在的 worker 能收到 <code>ok == false并自然退出 - 随后调用
wg.Wait()，确保所有已领取任务的 worker 全部结束
关键点：ctx.Done() 在这里只用于中断「等待新任务」阶段，不干预「执行中任务」；真正控制生命周期的是通道关闭 + WaitGroup。
cancel() 调用时机和 defer 的坑
常见错误是把 cancel() 放在启动 worker 后立刻 defer，结果还没等 worker 运行就取消了。正确做法是：在明确要终止时才调 cancel()，且通常应放在和 wg.Wait() 同一作用域的末尾。
- 不要在 goroutine 内部 defer
cancel()—— 它会立即触发，不是你想的“goroutine 结束时” - 如果用
context.WithTimeout()，超时后ctx.Done()自动关闭，但依然要确保 worker 正确响应，不能依赖超时自动清理 - 多个 worker 共享同一个
ctx没问题，但别重复调cancel()，第二次调是空操作，但可能掩盖逻辑错误
最易被忽略的一点：worker 内部如果又派生了子 goroutine（比如异步日志、回调通知），它们也得接收并传递同一 ctx，否则取消信号传不下去。
