直接用 goroutine 会因无节制创建导致内存暴涨、调度开销激增甚至 OOM；worker pool 通过任务队列、固定 worker 和结果通道实现限流；需合理设缓冲与 worker 数量，并用 WaitGroup + range 安全关闭。
为什么直接用 goroutine 会出问题
并发任务量大时，无节制启动 goroutine 会导致内存暴涨、调度开销激增，甚至触发 runtime: out of memory 或系统级资源耗尽。Go 的 goroutine 虽轻量，但每个仍需约 2KB 栈空间（初始），上万并发就可能吃掉几十 MB 内存；更关键的是，大量 goroutine 竞争 CPU 和 I/O，反而降低吞吐。
worker pool 的核心结构怎么搭
典型三组件：任务队列（chan Job）、固定数量的 worker（go worker()）、结果通道（可选 chan Result）。所有任务统一发到输入 channel，worker 持续从该 channel 取任务执行，避免重复创建/销毁 goroutine。
关键点：
-
Job类型需定义明确，通常含 ID、参数、回调或返回值字段 - 输入 channel 建议带缓冲（如
make(chan Job, 100)），防生产者阻塞；但缓冲区不宜过大，否则失去限流意义 - worker 数量不是越多越好，一般设为
runtime.NumCPU()的 1–4 倍，取决于任务是 CPU 密集还是 I/O 密集
如何安全关闭 worker pool
常见错误是直接 close 输入 channel 后立刻 return，导致部分 worker 还在读取已关闭 channel 并 panic（panic: send on closed channel 或读取零值）。正确做法是用 sync.WaitGroup 等待所有 worker 退出，并配合 context.Context 实现可取消的等待。
示例关闭逻辑：
func (p *Pool) Shutdown() {
close(p.jobs)
p.wg.Wait()
}
对应 worker 中必须用 for job := range p.jobs，而非 for { select { case job := —— 后者在 channel 关闭后会持续收到零值，除非显式检查 ok。
要不要加超时和重试机制
纯 worker pool 不处理任务失败，它只负责调度。是否加超时/重试，取决于业务场景：
- HTTP 请求类任务：建议在
Job.Run()内部用context.WithTimeout()控制单次执行时间 - 幂等操作（如写 DB）：可封装重试逻辑到 Job 结构体中，由 worker 调用
job.ExecuteWithRetry() - 非幂等操作（如发短信）：重试需谨慎，应交由上层业务决定，worker pool 只返回 error 让调用方处理
注意：不要在 worker 内部对整个 for range 加 context 超时，那会杀死整个 worker，而不是单个任务。
真正容易被忽略的是 worker 的“健康状态”——没有运行时监控时，某个 worker 卡死（比如死锁、无限循环、未 recover 的 panic）会导致任务积压且无感知。上线前务必加 recover() + 日志，并考虑用 time.AfterFunc 定期检查 channel 积压量。