最直观的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)
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语言免费学习笔记（深入）”；
云模块网站管理系统3.1.03
云模块_YunMOK网站管理系统采用PHP+MYSQL为编程语言，搭载自主研发的模块化引擎驱动技术，实现可视化拖拽无技术创建并管理网站！如你所想，无限可能，支持创建任何网站：企业、商城、O2O、门户、论坛、人才等一块儿搞定！永久免费授权，包括商业用途； 默认内置三套免费模板。PC网站+手机网站+适配微信+文章管理+产品管理+SEO优化+组件扩展+NEW Login界面.....目测已经遥遥领先..
下载
-
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 或limiter.Wait()失败 - 别直接用
eg.SetLimit(N)—— 它只限制 goroutine 启动速率，不控制实际并发数，容易误解
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel()sem := make(chan struct{}, 5) eg, egCtx := errgroup.WithContext(ctx)
for i := 0; i < 20; i++ { i := i eg.Go(func() error { sem <- struct{}{} defer func() { <-sem }()
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 日志、以及你用的到底是「控并发」还是「控速率」——这两者解决的问题完全不同，选错工具，后面调参都是白忙。
