Golang怎么用rate包实现限流器_Golang如何用官方库控制请求速率和并发量【进阶】-Golang-PHP中文网

rate.Limiter 不能直接限制并发数，它基于令牌桶控制单位时间调用次数，不统计或阻塞活跃 goroutine；需用 semaphore.Weighted 或信号量机制实现真正的并发控制。

golang怎么用rate包实现限流器_golang如何用官方库控制请求速率和并发量【进阶】

不能。rate.Limiter 本质是令牌桶，只管「单位时间放行多少次」，不管当前有多少请求在跑。它不维护 goroutine 状态，也不阻塞或统计活跃连接——所以你用 rate.NewLimiter(10, 5) 控制的是每秒最多 10 次调用，不是最多 10 个并发。

如果你要硬控并发量（比如最多同时处理 3 个 HTTP 请求），得配合 semaphore.Weighted（Go 1.21+）或自己用 sync.WaitGroup + chan struct{} 做信号量。rate 包只负责“节奏”，不负责“人数”。

误以为 limiter.Wait(ctx) 能拦住第 11 个 goroutine 同时执行？错——它只是让第 11 次调用等，但 goroutine 早已启动
HTTP handler 里只套一层 limiter.Wait，结果后端服务还是被打挂，因为并发峰值没被削平
真正要压并发，得在进 handler 前就卡住，比如用 semaphore.Acquire 配合超时 ctx

Wait 会阻塞直到拿到令牌（或 ctx 超时），TryWait 立即返回 bool：true 表示抢到了，false 表示桶空了、不等。

选哪个取决于你的错误容忍策略：要保响应延迟就用 TryWait，快速失败；要保成功率且能接受小延迟就用 Wait。

burst 是令牌桶的“容量”，也就是桶最多存几个令牌。设太大（比如 rate.NewLimiter(rate.Every(time.Second/10), 100)）会让限流形同虚设——前 100 次请求几乎不被限，瞬间打满下游。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

它不是缓冲队列，而是“突发许可额度”。真实流量突增时，burst 会一次性被清空，之后才开始按 rate 匀速补充。

每个请求都调 limiter.Wait(r.Context()) 是基本操作，但容易漏掉两点：panic 恢复后的重复调用、中间件顺序错位。

关键不是“加不加”，而是“在哪加、加几次、失败后怎么兜底”。

务必放在所有可能 panic 的中间件之前（比如 recover 中间件之后加限流，panic 后可能又走一遍 limiter）
不要在多个中间件里重复调 Wait，否则一次请求扣多次令牌
错误响应要带明确 header：w.Header().Set("X-RateLimit-Remaining", strconv.Itoa(int(limiter.Burst()-limiter.ReserveN(time.Now(), 1).Delay()))) —— 实际别这么算，用 limiter.Limit() 和自定义计数更稳
测试时用 httptest.NewRequest + context.WithTimeout 模拟超时，验证 Wait 是否真返回 error

rate 包本身很轻，但组合使用时边界条件多：ctx 取消时机、burst 和 rate 的比例、与其它同步原语的协作……最容易忽略的是——你限的到底是「请求频率」，还是你以为的「资源占用强度」。后者往往得靠更上层的控制手段来补。