最直观的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 日志、以及你用的到底是「控并发」还是「控速率」——这两者解决的问题完全不同，选错工具，后面调参都是白忙。
https://www.php.cn/faq/1982903.html