golang限流器怎么设置-Golang-PHP中文网

rate.newlimiter(rate.limit, burst)的两个参数分别是令牌生成速率（每秒补充令牌数，float64）和桶最大容量（int），burst至少应与rate相当（如rate.limit(10)配burst=10），过小导致首秒大量拒绝，过大则限流失效；rate

golang限流器怎么设置

rate.NewLimiter 的两个参数不是“每秒多少次”和“最多并发几路”，而是「令牌生成速率」和「桶最大容量」。设错 burst 或 rate.Limit 会导致限流形同虚设，或第一秒就全拒。

第一个参数是 rate.Limit（float64 类型），单位是「事件/秒」；第二个是 burst（int），代表桶最多能存多少令牌。

rate.Limit(10) 表示每秒补 10 个令牌，不是“每秒放行 10 次”——实际能否放行，取决于桶里有没有令牌
burst 至少为 1，设成 0 会 panic；设成 1 时，哪怕速率是 100，第一秒也只放过 1 次，其余全拒
常见错误配置：rate.NewLimiter(10, 1) → 突发流量直接打满即拦；正确应为 rate.NewLimiter(10, 10) 或 rate.NewLimiter(10, 20)，burst 建议取 QPS 的 2–3 倍
rate.Limit 小于 0.01（如 0.005）时，因纳秒级精度丢失，行为不可靠；想表达“每 200ms 一次”，直接写 rate.Limit(5)，别用 rate.Every(200 * time.Millisecond)

三者语义不同，混用会出问题：

Golang Uber Dig

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

下载

Allow() 立即返回 bool，适合健康检查等允许快速失败的场景；但它不提供等待时间、剩余令牌数，运维无法排查
WaitN(ctx, n) 是 HTTP 中间件首选：它会自动挂起 goroutine 直到拿到 n 个令牌，或 ctx 超时；务必传带超时的 context，比如 context.WithTimeout(r.Context(), 100*time.Millisecond)
ReserveN(now, n) 是唯一支持「一次扣多个令牌」的方式（如上传大文件、批量导出），但必须复用同一个 now := time.Now() 时间戳，且调完后显式执行 res.Fulfill() 或 res.CancelAt(now)
错误用法：在 handler 里先 Allow() 再手动 sleep，等于自己实现低效排队；或对同一请求多次调 time.Now()，导致令牌计算飘忽

*rate.Limiter 本身线程安全，但它不绑定任何标识——同一个实例无法区分用户 A 和用户 B。

共用一个实例做 per-user 限流，等于把所有用户塞进同一个桶，恶意用户刷接口会把别人全堵死
必须为每个 key（如 c.ClientIP()、JWT 解析出的 sub）创建独立的 *rate.Limiter
用 sync.Map 缓存，key 是标准化后的 IP 或 userID（注意 IPv6 冒号处理），value 是对应 limiter
长期存活的 limiter 不会自动 GC，需定期清理：给每个 entry 记录最后访问时间戳，后台 goroutine 每分钟扫一次，淘汰 5 分钟无访问的 entry

不是“加了限流逻辑”就万事大吉，真正线上出问题的，往往卡在这些细节：

没提取真实 IP：直接用 r.RemoteAddr 会被代理层污染，要从 X-Forwarded-For 或 X-Real-IP 提取，且确认来源可信
没返回标准头：拒绝请求时，除了 429 Too Many Requests，必须设 Retry-After 头（值可取 res.Delay().Seconds()），否则前端无法退避重试
没处理 panic 场景：若 handler 已执行部分业务再 panic，defer res.Cancel() 会导致令牌白占不扣，桶迅速变空；应改用 res.Fulfill() 在成功路径显式调用
所有时间相关操作（AllowN、ReserveN、Wait）都依赖传入时间戳是否一致——单请求内混用多次 time.Now()，尤其在容器或虚拟机里，时钟抖动会让限流结果完全不可预测

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！