rate.NewLimiter的Limit和Burst必须协同设置：Limit为每秒令牌生成速率（次/秒），Burst为桶最大容量（个），Burst至少等于Limit，推荐设为Limit的2–3倍以应对突发；二者配错会导致限流失效或首秒大量拒绝。
直接用 golang.org/x/time/rate.Limiter 就能防雪崩，但配错 Limit 和 Burst 会立刻失效——比如设了 10 QPS 却连 3 次请求都放不过。
rate.NewLimiter 的两个参数怎么设才不翻车
不是“越大越好”，也不是“随便填”。Limit 是每秒平均发放的令牌数（单位：次/秒），Burst 是桶最大容量（单位：个），二者必须协同：
-
Burst必须 ≥Limit，否则新速率永远达不到。例如Limit=10但Burst=5，桶最多存 5 个 token，再快也白搭 - 想扛突发流量，
Burst可设为Limit × 2或更高（如 10 QPS 配Burst=20）；纯匀速场景可设为和Limit相同 - 别写
rate.Every(time.Second / 10)这种表达式——Go 编译器可能优化掉除法，应显式写rate.Limit(10) - 刚把
Limit从 5 改成 10，下一秒调Allow()仍可能只成功 4 次：因为 token 是按时间推算补的，不是瞬间重置；上一秒只攒了不到 10 个，还受Burst上限压制
HTTP 中间件里怎么安全嵌入 Limiter 实例
不能全局共用一个 *rate.Limiter，也不能每个请求 new 一个——得按维度隔离 + 并发安全缓存：
- 单个实例无法区分来源，硬套在中间件里会导致所有用户共享一桶，失去限流意义
- 用
sync.Map缓存不同 key 对应的限流器，key 推荐用清洗后的X-Forwarded-For（防代理污染），避免直接用c.Request.RemoteAddr - IPv6 地址含冒号，当 key 时需先标准化（如转为 IPv4-mapped 或哈希截断），否则
sync.Map键长失控 - 对
GET /health这类探活接口，务必绕过限流，否则健康检查失败会触发雪崩
Allow()、Reserve()、Wait() 到底该选哪个
三者都消费 token，但失败处理逻辑完全不同，选错会导致阻塞、超时或误拒：
立即学习“go语言免费学习笔记（深入）”；
-
Allow()立即返回 bool，适合快速拒绝（如 HTTP 429），但不提供等待能力 -
Reserve()返回*rate.Reservation，可判断是否允许、并手动Cancel()或Delay()，适合需要精细控制延迟的场景（如后台任务排队） -
Wait()会阻塞直到拿到 token 或 context 超时，容易拖慢整个请求链路；若后端慢，令牌被长期占用，实际吞吐远低于配置值 - 生产环境推荐优先用
Allow()做入口快速拦截，除非业务明确要求排队等待
单机限流够不够？什么时候必须上 Redis+Lua
单机 rate.Limiter 能稳住大多数 API 流量，但有明确边界：
- 全局限流适合防雪崩（如网关层兜底），用一个固定实例放在最外层 middleware，
Allow()失败直接中断请求 - 按用户、IP、租户等维度限流，必须做 key 隔离，此时单机方案天然支持，无需 Redis
- 集群部署且需强一致性限流（如支付接口严格 100 QPS 总量），必须用
Redis+Lua实现分布式令牌桶；单机rate.Limiter在多实例下无法协同 -
Redis方案带来额外延迟和运维成本，别为了“看起来更高级”而提前引入——先压测单机能否扛住峰值
真正容易被忽略的是：限流器本身不解决后端慢的问题。它只拦请求，不加速服务。如果下游响应 P99 达到 2s，即使限流设成 100 QPS，实际吞吐也可能卡在 0.5 QPS——这时候该查的是超时、熔断、DB 连接池，而不是调大 Burst。
