推荐用 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:
// 获取成功
defer func() { token <- struct{}{} }()
doHTTPCall()
default:
// 无可用令牌，快速失败
return
}
}
用 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。
