直接用for range tasks { go handle(task) }会崩，因失控并发导致内存暴涨、下游429、DNS失败或OOM kill；必须用固定worker数+带缓冲channel限流，关闭需三步协同：停投递→等消费→收结果。
直接用 go handle(task) 处理并发任务，在微服务里大概率会崩——不是代码写错了，是并发数失控导致内存暴涨、下游 429、DNS 查不到、甚至被 OOM kill。
为什么不能 for range tasks { go handle(task) }
微服务面对的是真实流量：秒级数千请求、批量日志上报、定时拉取上游数据。每个请求 spawn 几十个 goroutine，瞬间就上万。goroutine 虽轻量，但默认栈 2KB，10k 就吃掉 20MB+ 内存；调度器扛不住，GC 频繁，pprof 一眼看到 goroutine 数卡在 15k 不动。
- 典型错误现象：
runtime: out of memory、dial tcp: lookup failed、HTTP client 报429 Too Many Requests - 根本原因不是逻辑错，是没做硬性并发节制——你把控制权交给了输入规模，而不是系统容量
- sync.Pool 完全不适用：它管对象复用，不管任务排队、限流、超时，更不保证“谁来执行”
jobs channel 该用带缓冲还是无缓冲
微服务场景下，几乎必须用带缓冲：make(chan Job, 1000)。无缓冲 channel（make(chan Job, 0)）会让生产者（比如 HTTP handler）在没空闲 worker 时直接阻塞，拖垮整个请求链路，尤其在短生命周期上下文中极其危险。
- 缓冲大小设为预期最大积压量，比如峰值 QPS × 平均处理耗时 × 2，常见取值 100–5000
- 缓冲区不是“越多越好”：太大可能掩盖背压，让任务在队列里滞留过久，超时丢失
- 若需强实时流控（如风控决策），才考虑无缓冲 + context 超时组合，但要求 worker 始终在线且响应稳定
worker 怎么安全退出不 panic
关闭不是调个函数，而是三步原子协同：停投递 → 等消费 → 收结果。漏一步就死锁或 send on closed channel panic。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
立即学习“go语言免费学习笔记（深入）”；
- 主 goroutine 必须先
close(jobChan)，绝不能在 worker 里 close - worker 必须用
for job := range jobChan或job, ok := 感知关闭，不能只 <code>select监听不判ok -
sync.WaitGroup.Add()要在启动所有 worker 前完成；每个 worker 结束前必须wg.Done()（建议 defer） - resultChan 若有缓冲，发送前务必用
select+default非阻塞写，失败则记录告警——否则写满后 worker 会 panic 静默退出
要不要支持动态增减 worker 数量
不要。Worker Pool 是为稳态吞吐设计的，不是抗突发的。所谓“动态扩缩容”，实际要安全启停 goroutine、重分配未完成任务、清理中间状态——这些逻辑远比池子本身复杂，极易引入 data race 和泄漏。
- 突发流量该用前置限流：比如
golang.org/x/time/rate.Limiter挡掉超额请求 - 长期负载变化？说明初始配置不合理，应重新压测调整固定 worker 数：IO 密集型（HTTP/DB）设为
runtime.NumCPU() * 3 ~ * 4，CPU 密集型不宜超核数 - 真需要弹性，用成熟库如
ants，它已封装 panic 捕获、超时控制、自动伸缩策略，别自己造轮子
最易被忽略的一点：Job 结构体里必须带可追溯字段（如 ID string），Result 必须回传该字段和 error；否则任务失败了，你连哪条 URL 抓崩了都查不到。
