Go高并发核心是协程池与限流协同：协程池通过固定worker复用goroutine、缓冲任务实现有序吞吐；限流在入口层基于令牌桶控制请求速率，二者需限流前置、池内任务channel设上限并用非阻塞提交。
用 
Go 处理高并发请求，核心不是堆机器，而是让每个 goroutine 做得更少、更准、更可控。协程池 + 限流不是炫技组合，而是把“无序并发”变成“有序吞吐”的关键控制层。
协程池：避免 goroutine 泛滥，复用执行单元
直接用 go fn() 启动成千上万个 goroutine，看似轻量，但调度开销、内存占用、上下文切换成本会随并发数非线性上升。协程池通过固定数量的工作协程 + 任务队列，把并发压力“缓冲”和“节流”在池子内部。
- 用
workerpool（如 tidwall/workerpool）或手写带 channel 的 worker 模型：启动 N 个长期运行的 goroutine，从一个共享 channel 拉取任务 - 池大小建议设为
2 × CPU 核数起步，再根据实际 CPU 利用率与 P99 延迟压测调整；纯 I/O 密集可略高，计算密集务必保守 - 任务函数应尽量无状态、快速返回；耗时操作（如 DB 查询、HTTP 调用）仍需单独超时控制，不能依赖池本身阻塞等待
限流：守住系统水位线，防雪崩从入口开始
协程池管的是“内部怎么跑”，限流管的是“外部能塞多少进来”。两者叠加，才能避免突发流量击穿下游或耗尽本地资源。
- 推荐使用
golang.org/x/time/rate的Limiter：基于令牌桶，支持平滑限流（如每秒 1000 请求），也支持突发（burst 参数预留缓冲） - 在 HTTP handler 最外层或中间件中校验：
if !limiter.Allow() { http.Error(w, "Too Many Requests", http.StatusTooManyRequests); return } - 对不同接口、用户等级、API Key 分别配置限流策略，可用 map[string]*rate.Limiter 实现多维度隔离；注意 key 高并发读写时加读写锁或使用
sync.Map
协程池 + 限流协同的关键细节
二者不是简单拼接，配合不当反而引入瓶颈或失效。
- 限流应在协程池 之前：先拦住超额请求，再交由池子处理；否则限流失去意义，池子可能被塞爆
- 协程池的任务 channel 容量要设上限（如 1000），并启用非阻塞提交（
select { case ch ），防止限流失效后任务持续堆积内存 - 监控必不可少：暴露池中排队数、拒绝数、limiter 当前剩余令牌数等指标（用 Prometheus + expvar），真正靠数据调参，而不是拍脑袋
一个极简落地示例（HTTP 服务片段）
不依赖第三方池库，50 行内搭出可用骨架：
var (
pool = workerpool.New(10) // 10 个工作协程
limiter = rate.NewLimiter(rate.Every(time.Second/100), 200) // 100 QPS，允许最多 200 突发
)
func handler(w http.ResponseWriter, r http.Request) {
if !limiter.Allow() {
http.Error(w, "rate limited", http.StatusTooManyRequests)
return
}
// 提交任务到池，带 context 控制超时
ctx, cancel := context.WithTimeout(r.Context(), 3time.Second)
defer cancel()
pool.Submit(func() {
select {
case <-ctx.Done():
return // 超时退出
default:
// 执行真实业务逻辑：DB / cache / call external
result := doWork(ctx)
// 写回响应需同步（不能在 goroutine 里直接 w.Write）
// 此处应改用 channel 或回调通知主 goroutine
}
})
}
注意：真实场景中响应写入必须在 handler goroutine 中完成，所以更稳妥做法是用 channel 等待结果或用 errgroup 控制生命周期。
