最直观的Go并发限流方式是用带缓冲的chan作许可证池，缓冲容量即最大并发数，每次goroutine启动前取值、结束后写回，配合sync.WaitGroup协调完成。
用 sync.WaitGroup + chan 做基础并发限流最直观
Go 里最轻量、最可控的限流方式，就是靠带缓冲的 chan 控制“同时运行的 goroutine 数量”。它不依赖第三方库，语义清晰，适合大多数场景。
核心思路：把 chan 当作“许可证池”，每次启动 goroutine 前先 take（从 chan 取一个值），执行完再 put（写回一个值）。缓冲区容量即最大并发数。
- 缓冲大小设为
N，就严格保证最多N个 goroutine 并发执行 - 阻塞发生在
ch ，而不是业务逻辑里，调度开销极小 - 注意别漏掉
defer归还令牌，否则会永久泄漏
func main() {
const maxConcurrent = 3
sem := make(chan struct{}, maxConcurrent)
<pre class='brush:php;toolbar:false;'>var wg sync.WaitGroup
for i := 0; i < 10; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
sem <- struct{}{} // 获取许可
defer func() { <-sem }() // 归还许可
fmt.Printf("task %d starts\n", id)
time.Sleep(time.Second) // 模拟工作
fmt.Printf("task %d done\n", id)
}(i)
}
wg.Wait()}
用 golang.org/x/time/rate.Limiter 控制请求速率而非并发数
rate.Limiter 不是并发数限制器，而是「单位时间请求数」控制器（比如 QPS=10）。它基于令牌桶算法，适合 API 网关、下游服务防刷等场景，和上面的并发控制目标不同，别混用。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
rate.NewLimiter(rate.Every(100*time.Millisecond), 1)表示每 100ms 最多放行 1 个请求（≈10 QPS） -
limiter.Wait(ctx)会阻塞直到拿到令牌；limiter.Allow()则立即返回 bool，适合非阻塞判断 - 注意：它不感知 goroutine 生命周期，只管“请求到达时间”，无法防止瞬时并发暴涨（比如 100 个 goroutine 同时调
Allow()，前b个会成功）
limiter := rate.NewLimiter(rate.Every(200*time.Millisecond), 1)
for i := 0; i < 5; i++ {
go func(id int) {
if err := limiter.Wait(context.Background()); err != nil {
log.Printf("task %d rejected: %v", id, err)
return
}
fmt.Printf("task %d allowed at %s\n", id, time.Now().Format("15:04:05"))
}(i)
}
time.Sleep(time.Second * 2)用 errgroup.Group 替代 sync.WaitGroup 实现带取消的并发限流
当需要在限流基础上支持超时或主动中断（比如用户取消请求），errgroup.Group 比裸写 WaitGroup 更安全。它内置 context 支持，且自动传播第一个错误。
- 调用
eg.Go()启动任务，内部已处理 panic 捕获和 error 返回 - 传入的
context.Context被所有 goroutine 共享，任意一个 cancel 都会让其余等待中的sem 或 <code>limiter.Wait()失败 - 别直接用
eg.SetLimit(N)—— 它只限制 goroutine 启动速率，不控制实际并发数，容易误解
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<p>sem := make(chan struct{}, 5)
eg, egCtx := errgroup.WithContext(ctx)</p><p>for i := 0; i < 20; i++ {
i := i
eg.Go(func() error {
sem <- struct{}{}
defer func() { <-sem }()</p><pre class='brush:php;toolbar:false;'> select {
case <-time.After(1 * time.Second):
fmt.Printf("task %d completed\n", i)
return nil
case <-egCtx.Done():
return egCtx.Err()
}
})}
if err := eg.Wait(); err != nil { fmt.Printf("stopped early: %v\n", err) }
别忽略 runtime.GOMAXPROCS 和 GC 对限流效果的影响
限流逻辑本身再精确，也挡不住底层调度和内存压力带来的抖动。尤其在高并发短任务场景下，这两个点常被忽视：
-
GOMAXPROCS默认等于 CPU 核心数，但若大量 goroutine 频繁阻塞/唤醒（如密集 I/O），适当调高（比如runtime.GOMAXPROCS(16)）可减少调度排队延迟，让sem更快被释放 - 频繁创建小对象（如每个任务 new 一个 struct）会加剧 GC 压力，导致 STW 时间变长，间接拉长任务平均耗时，使限流“看起来”失效（比如设定 5 并发，但因 GC 卡顿，实际完成更慢）
- 验证方法：跑压测时用
go tool trace看 goroutine block 和 GC 时间占比，比单纯看 QPS 更准
限流不是加个 channel 就万事大吉。真正稳定，得盯住调度器行为、GC 日志、以及你用的到底是「控并发」还是「控速率」——这两者解决的问题完全不同，选错工具，后面调参都是白忙。
