工作池是go并发的节流阀：必须固定worker数量、使用带缓冲channel、显式管理生命周期；直接for range go会失控引发oom、调度卡顿和下游503。
直接用 for range tasks { go handle(task) } 调度 worker，等于把系统交给运气——10 万任务就拉起 10 万 goroutine，内存暴涨、调度卡顿、下游服务直接 503 Service Unavailable。必须用固定数量的 worker + 带缓冲 channel 控制并发节奏。
为什么不能直接 go handle(task)？
这行代码把并发控制权完全交给了任务数量，而不是你的资源上限。每个 goroutine 默认栈至少 2KB，10 万并发就是 200MB+ 内存；调度器要维护所有 goroutine 状态，活跃数上万时延迟毛刺明显；更致命的是，数据库连接池、HTTP client pool 这类下游组件都有硬限制，瞬间打满就会拒绝服务。
常见错误现象包括：runtime: out of memory、too many concurrent operations on a single file or socket、CPU 跑满但吞吐没涨。
goroutine 轻量 ≠ 零成本。失控的并发不是“快”，而是“崩”。
worker pool 必须用带缓冲 channel 吗？
绝大多数场景下，make(chan Job, N) 是唯一合理选择，N 一般设为预期最大待处理任务数（比如 1000）。无缓冲 channel（make(chan Job, 0)）会让提交方在没空闲 worker 时直接阻塞，对 HTTP handler 这类短生命周期调用极不友好，容易拖垮整个请求链路。
- 带缓冲能吸收突发流量，避免生产者卡住
- 但缓冲区过大可能掩盖积压问题（比如 worker 处理变慢却无感知）
- 无缓冲只适合强背压场景，且要求 worker 始终在线、响应及时——这在真实服务中很难保障
- 缓冲大小建议 ≥ 单次批量任务数，否则
jobs 可能阻塞主 goroutine
worker 怎么安全退出不 panic？
退出顺序只有一条铁律：所有任务发完 → close(jobs) → wg.Wait() → (可选) close(results)。错一步就死锁或 panic。
job, ok := 是感知关闭的唯一方式，别用 <code>range jobs——它会在close(jobs)后自动退出，但无法区分是空 channel 还是已关闭-
wg.Add()必须在启动 worker 前完成 -
wg.Done()必须在每个 worker 退出前执行，推荐写成defer wg.Done() - 千万别在 worker 里
close(results)——多个 goroutine 同时 close 同一个 channel 会 panic
要不要支持动态增减 worker 数量？
不要。Worker Pool 是为稳态吞吐设计的，不是扛突发流量的。所谓“动态扩缩容”，实际意味着你要安全启停 goroutine、重分配未完成任务、处理中间状态——这些逻辑远比池子本身复杂，极易引入竞态和泄漏。
突发流量该用前置限流（如 golang.org/x/time/rate）或消息队列削峰。如果真需要弹性，建议换成熟第三方库（如 ants 或 pond），它们已封装 RunningWorkers()、Tune()、PriorityTask 等逻辑。
最常被忽略的一点：worker 池不是性能优化手段，而是稳定性兜底机制。它的价值不在“跑得更快”，而在“崩得更慢”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
