Golang限制并发请求数量的常见做法

推荐用 golang.org/x/sync/semaphore 控制并发：NewWeighted 设置最大并发数，Acquire/Release 配对使用 defer 保证释放，支持超时与非阻塞 TryAcquire。

用 semaphore 控制并发请求数（推荐）

Go 标准库没有内置信号量，但可以用 sync.Mutex + sync.Cond 或第三方库（如 golang.org/x/sync/semaphore）实现。后者更轻量、语义清晰，是目前最主流的做法。

注意：不要自己手写带计数的互斥锁——容易漏掉 Unlock 或在 panic 时未释放，导致死锁或资源耗尽。

• semaphore.Weighted 支持非阻塞获取（TryAcquire），适合做快速失败判断
• 每个请求应对应一次 Acquire 和一次 Release，建议用 defer 保证释放
• 初始权重值即最大并发数，比如 semaphore.NewWeighted(10) 表示最多 10 个并发

import "golang.org/x/sync/semaphore" 
var sem = semaphore.NewWeighted(5)
func handleRequest() { if err := sem.Acquire(context.Background(), 1); err != nil { // 超时或上下文取消 return } defer sem.Release(1)
// 执行实际请求逻辑 dohttpCall()
}
立即学习“go语言免费学习笔记（深入）”；
用 channel 做固定容量的并发令牌池
本质是用带缓冲的 channel 当作“令牌桶”，每次请求前从 channel 取一个空位，完成后放回。简单直接，不依赖外部包，适合轻量场景。
缺点是无法设置超时等待、不能动态调整容量，且容易误用：chan Struct{} 容量设错或忘记 close 后的读取会 panic。

必须初始化为带缓冲的 channel：make(chan struct{}, 10) 
获取令牌用 select + default 可做非阻塞尝试
务必确保每次成功获取后都有对应的 send 回 channel，否则池子会逐渐枯竭

var token = make(chan struct{}, 3) 
func init() { for i := 0; i < cap(token); i++ { token <- struct{}{} } }
func handleRequest() { select { case <-token: >
用 worker pool 模式统一调度请求
 
当并发控制只是起点，后续还要做任务排队、优先级、重试、统计等，就该上 worker pool。它把“限制并发”变成“固定数量 goroutine 持续消费任务队列”，更易扩展和观测。
 
注意：别让 worker 数量远小于任务量又不加队列缓冲，会导致大量任务被丢弃；也别让队列无限增长，引发 OOM。
 
 
worker 数量即最大并发数，通常设为 CPU 核心数或 IO 密集型场景下的经验值（如 10–50）
 
任务 channel 应设缓冲（如 make(chan *Request, 1000)），避免生产者阻塞
 
需显式关闭 channel 并等待所有 worker 退出，否则 range 不会结束
 
func startWorkerPool(n int, jobs <-chan *Request) {     var wg sync.WaitGroup     for i := 0; i < n; i++ {         wg.Add(1)         go func() {             defer wg.Done()             for req := range jobs {                 doHTTPCall(req)             }         }()     }     wg.Wait() }
别踩 time.Sleep 或 runtime.Gosched 的坑
有人试图用休眠或主动让出调度来“限速”，这是无效的。它们既不限制并发数，也不控制资源占用，只拖慢单个 goroutine，反而可能因堆积更多 goroutine 加剧内存压力。
尤其要注意：在 HTTP handler 中用 time.Sleep 等待，会占用整个 goroutine 直到超时，而 Go 的 HTTP server 默认为每个请求启一个 goroutine——等于人为制造 goroutine 泄漏。

 time.Sleep 是时间控制，不是并发控制
 runtime.Gosched 只建议用于防止长时间独占 P，不解决并发上限问题
真正要控的是“同时执行的请求数”，不是“请求之间隔多久”

真正难的不是选哪种方式，而是确定那个数字：最大并发数设成多少？它得结合下游服务的吞吐能力、本机 CPU/内存余量、请求平均耗时和 p99 延迟目标来反复压测，而不是拍脑袋填个 10 或 100。