Go 给了我们很轻量的 goroutine，但这不代表可以无限并发。
在后端服务里，并发数量如果失控，通常会先压垮数据库和下游服务，而不是 CPU。
为什么要 Worker Pool
Worker Pool 的核心价值是把“任务量”与“并发度”解耦。
常见模式是：
- 任务通过 channel 投递
- 固定数量 worker 消费任务
- 通过 context 控制超时和取消
这个模型能让系统在高峰期更稳定，而不是一波请求把资源打空。
一个实用的三层保护
我在生产里更常用“三层保护”组合：
- API 层限流（防突发）
- Worker Pool 控并发（防资源过载）
- 下游调用超时 + 重试预算（防雪崩）
它的目标不是追求峰值吞吐，而是保证在异常流量下还能优雅退化。
监控指标要盯什么
只看 QPS 不够，至少再盯三项：
- 任务队列长度
- 平均等待时长
- 超时和取消比例
这些指标能比错误率更早暴露系统压力。
小结
Go 并发的真正优势，不是“能起很多 goroutine”，而是能用简单模型把系统稳定性做出来。
后端性能优化里，稳定比峰值更值钱。