不能用for range tasks { go handle(task) }，因会失控并发：10万任务即启10万goroutine，内存暴涨超200MB、调度卡顿、下游服务拒绝；正确做法是worker pool+带缓冲channel限流控并发。
为什么不能用 for range tasks { go handle(task) }
这行代码等于把并发控制权完全交给任务数量——10 万条日志、10 万次 HTTP 请求，就会瞬间拉起 10 万个 goroutine。每个默认栈至少 2KB，光内存就吃掉 200MB+；更严重的是调度器需维护所有 goroutine 状态，活跃数上万时延迟毛刺明显。下游服务（如数据库连接池、HTTP client pool）通常有硬限制，瞬间打满直接拒绝服务。
- 常见错误现象：
runtime: out of memory、too many concurrent operations on a single file or socket、CPU 跑满但吞吐没涨 - 根本原因：goroutine 轻量 ≠ 零成本；失控的并发不是“快”，而是“崩”
- 正确思路：worker pool 不是为加速而生，是为控流——用固定数量 goroutine 持续消费任务队列
jobs 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。
-
close(jobs)只能由生产者（主 goroutine）调用一次；worker 里关会 panic - worker 必须用
for job := range jobs或job, ok := 感知关闭，不能用select单独监听而不判ok -
sync.WaitGroup的Add()要在启动 worker 前完成，Done()必须在每个 worker 退出前执行（推荐defer wg.Done()） - 别依赖
range自动退出就省略清理——它不会等你写完日志、归还资源再走
要不要支持动态增减 worker 数量
不要。Worker Pool 是为稳态吞吐设计的，不是扛突发流量的。所谓“动态扩缩容”，实际意味着你要安全启停 goroutine、重分配未完成任务、处理中间状态——这些逻辑远比池子本身复杂，极易引入竞态和泄漏。
- 突发流量该用前置限流（如
golang.org/x/time/rate）或消息队列削峰 - 如果真需要弹性，建议换成熟第三方库（如
ants或pond），它们已封装 RunningWorkers()、Tune()、PriorityTask 等逻辑 - 手写 pool 足够应对 90% 场景；过早引入动态伸缩，反而让 shutdown 和 error recovery 变得不可靠
真正难的从来不是启动几个 goroutine，而是让它们在任务来、任务走、出错、重启、超时这些真实边界条件下，不 panic、不漏任务、不卡死 channel。这些细节藏在 close 时机、range 退出条件、WaitGroup 传参方式里，稍一松懈就埋下线上故障的种子。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
