微服务中不能直接 go handle(req) 是因为会失控并发——1000 QPS 就启 1000 goroutine，内存暴涨、调度卡顿、下游连接池打满致 503 或 OOM；Worker Pool 是安全阀，需固定 worker 数 + 带缓冲 channel（如 make(chan Job, 1000)）防 HTTP handler 阻塞。
为什么微服务里不能直接 go handle(req)
微服务接口一压就崩，不是代码逻辑错，而是 go handle(req) 把并发控制权交给了请求量——1000 QPS 就拉起 1000 个 goroutine，每个默认栈 2KB，光内存就吃掉 2MB+，加上调度开销、HTTP client 连接池打满、下游 DB 拒绝连接，503 Service Unavailable 和 runtime: out of memory 就成了常态。Worker Pool 在这里不是“加速器”，是“安全阀”：把不可控的请求流，塞进固定数量的长期 worker 里匀速消费。
jobs channel 用带缓冲还是无缓冲
微服务场景下，几乎必须用带缓冲：make(chan Job, 1000)。原因很实际：
- HTTP handler 生命周期短（毫秒级），若用无缓冲
make(chan Job, 0)，当所有 worker 忙时，jobs 会立刻阻塞，整个 HTTP 请求卡住，超时、重试、雪崩全来了 - 带缓冲能吸收突发流量（比如秒杀、定时任务批量触发），给下游留出响应时间
- 缓冲区大小不是越大越好：设为预期峰值积压数（如 1000），太大可能掩盖真实积压，小了又起不到缓冲作用
- 别指望靠缓冲兜底——它只是缓冲，不是永动机；真正要防积压，得配前置限流（如
golang.org/x/time/rate）
worker 怎么安全退出不丢任务
微服务常需滚动更新或优雅停机，close(jobs) 时机错一步就死锁或丢数据。关键顺序只有三步，缺一不可：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先让 HTTP server 停止接收新请求（如调用
srv.Shutdown()） - 等所有已接收请求提交完任务后，再
close(jobs) -
sync.WaitGroup的Add()必须在启动 worker 前完成，Done()必须在每个 worker 退出前执行（哪怕 panic 也要 defer） - worker 内必须用
job, ok := 或 <code>for job := range jobs感知关闭，不能只select监听却不判ok，否则会永远等下去
结果怎么回传才不乱序、不丢失
微服务返回结果必须可追溯、不丢、不错位。全局 chan Result 是陷阱：
立即学习“go语言免费学习笔记（深入）”；
- 多个 worker 往同一个
resultschannel 写，结果顺序和任务顺序不一致，下游按序处理就会出错 - 如果
results无缓冲，worker 写入时主 goroutine 没在读，就会永久阻塞——尤其在优雅停机时，极易卡死 - 正确做法：每个
Job带一个resultChan chan 字段，worker 执行完直接发到该 task 自己的 channel；主 goroutine 用 <code>for i := 0; i 顺序收 - 若必须用全局
results，务必加缓冲（如make(chan Result, 1000)），并用select { case results 防写满 panic
微服务里的 Worker Pool 不是炫技，是保命。最容易被忽略的点是：任务通道关闭和结果通道关闭必须严格错开，中间隔着 wg.Wait() —— 关早了 worker 还在写 result，关晚了主 goroutine 等不到全部结果。这个时间窗口，没有自动机制能帮你兜底。
