golang.org/x/time/rate是Go生产环境限流的事实标准，基于无锁令牌桶算法，线程安全、纳秒级精度、支持突发流量；应复用实例，慎用Allow()，优先Reserve()+Wait()并配合context超时控制。
golang.org/x/time/rate 是 Go 生产环境限流的默认选择，不是“可选方案”，而是事实标准。它轻量、线程安全、无依赖、精度足够，且已被大量高并发服务验证。别自己手写或引入第三方轮子，除非你明确需要 rate.Limiter 不提供的能力（比如实时查询剩余令牌数、跨进程同步桶状态、或严格按 RFC 2697 实现）。
为什么用 rate.NewLimiter 而不是自己建 struct + mutex
常见错误是看到“令牌桶”就动手写带 tokens 字段和定时填充 goroutine 的结构体。这会引入几个隐性成本：
– 每个桶都要启一个 goroutine 填充，QPS 高时 goroutine 数爆炸
– 浮点运算累积误差（如每 100ms 加 0.1 个令牌，跑一天可能少几十个）
– sync.Mutex 在高并发下争抢严重，而 rate.Limiter 底层用 atomic + 时间戳推算，零锁
– 无法复用底层的 reserveN 逻辑，导致 burst 行为不可控
正确做法是直接调 rate.NewLimiter(rate.Every(100*time.Millisecond), 20)：第一个参数控制平均速率（每 100ms 放 1 个），第二个是最大突发数（最多攒 20 个）。
Allow() 和 Wait() 到底该用哪个
这两个方法行为差异极大，选错等于没限流：
– Allow() 纯判断，不阻塞，返回 bool。适合“快速失败”场景，但要注意：它不保证后续业务逻辑一定能执行完——如果后端处理慢，请求仍可能堆积
– Wait() 会阻塞直到拿到令牌（或 ctx 超时），真正把流量“削峰填谷”。HTTP handler 中应优先用它，避免前端重试放大压力
– 别在循环里反复调 Allow() 等令牌，这是反模式；用 Wait(ctx) 即可
– 如果用了 Wait()，记得传带 timeout 的 context.Context，否则客户端可能无限等待
按 IP 限流时，RemoteAddr 不能直接用
直接取 r.RemoteAddr 在有反向代理（Nginx、Cloudflare、ALB）时会得到代理地址，导致所有用户被当成同一个 IP 限流：
– 必须解析 X-Forwarded-For 或 X-Real-IP 头，但这些头可伪造，不能全信
– 生产环境应结合 TrustedProxies 列表做 IP 链校验（比如只信任内网网段的 XFF）
– 更稳妥的做法是让网关层（如 Envoy、API Gateway）做真实 IP 提取并注入到 X-Forwarded-For 最左字段，后端只取该值
– 代码里别用 map[string]*rate.Limiter 按 IP 新建实例，内存泄漏且 GC 压力大；改用 sync.Map + TTL 清理，或直接上 Redis + Lua 做分布式限流
立即学习“go语言免费学习笔记（深入）”；
burst 参数设成 1 就等于放弃弹性
burst 不是“允许超限次数”，而是令牌桶的容量上限。设成 1 会让算法退化为严格匀速漏桶：
– 用户双击刷新、前端 SDK 自动重试、CDN 预热请求都会被 429 拒绝，体验极差
– 正常 Web 服务建议 burst >= rate * 0.5（例如 10 QPS 对应 burst=5），给毛刺留余量
– 过大的 burst（比如 1000）会导致瞬时压垮后端，尤其当后端处理延迟波动时
– 它和 rate 是耦合参数：调高 rate 但不调 burst，突发抗性反而下降
