<p>golang.org/x/time/rate 是 Go 官方推荐的令牌桶限流方案，核心为 rate.Limiter 和 rate.Limit；需按需动态创建实例隔离限流维度，配合 Retry-After 和 X-RateLimit- headers 提升兼容性，注意时钟依赖与性能边界。</p>
Go 用 golang.org/x/time/rate 做令牌桶限流最稳妥
标准库没有内置限流，golang.org/x/time/rate 是官方维护、生产验证过的唯一推荐方案。别自己手写计数器或基于 time.Ticker 模拟，精度差、并发不安全、漏桶/令牌桶语义模糊。
它核心就两个类型：rate.Limiter（你直接用的）和 rate.Limit（每秒放多少令牌）。初始化时传入期望的 QPS 和最大突发量（burst），比如 rate.NewLimiter(10, 5) 表示平均 10 QPS，最多允许 5 次瞬时请求打进来。
-
limiter.Wait(ctx)是最常用方式：阻塞直到拿到令牌，适合必须执行的请求（如支付） -
limiter.Allow()返回 bool：立刻返回是否能执行，适合可降级场景（如日志上报） -
limiter.Reserve()返回*rate.Reservation：能精确控制等待时间或取消，但多数人用不到
HTTP 中间件里嵌 rate.Limiter 别共享实例
一个 rate.Limiter 实例是并发安全的，但如果你把同一个实例用在所有路由上，就变成全局限流——这通常不是你想要的。比如用户 A 和用户 B 共享配额，或者 /login 和 /api/data 被同一套规则卡住。
更常见的需求是按 IP、用户 ID 或 API 路径做隔离限流。这时候得动态生成 Limiter 实例，或用 map 缓存：
立即学习“go语言免费学习笔记（深入）”；
var limiters = sync.Map{} // key: ip string, value: *rate.Limiter
ip := r.RemoteAddr
limiter, _ := limiters.LoadOrStore(ip, rate.NewLimiter(5, 3))
注意：sync.Map 不适合高频写+低频读场景；如果 key 太多（比如每个用户都建一个），得加 LRU 清理逻辑，否则内存泄漏。
Allow() 返回 false 后怎么响应 HTTP 状态码
很多人调了 limiter.Allow() 发现返回 false 就直接 http.Error(w, "...", 503)，但这样没告诉客户端“什么时候能重试”。HTTP 标准建议配合 X-RateLimit-Reset 和 Retry-After 头。
-
limiter.Reserve()的Delay()方法能告诉你还要等多久（time.Duration），转成秒填进Retry-After -
limiter.Limit()和limiter.Burst()可以算出当前窗口剩余配额，填到X-RateLimit-Remaining - 别硬编码 429 状态码——有些老客户端只认 503，得看你的下游约定
高并发下 rate.Limiter 的性能和时钟依赖
它的底层靠 time.Now() 和 channel 实现，单实例压测能轻松扛住 10w+ QPS（实测数据），但有两个隐藏成本：
- 每次
Wait()都会触发一次系统调用获取当前时间，高频调用下time.Now()本身有开销（纳秒级，但积少成多） - 它假设系统时钟单调递增；如果发生 NTP 调整或虚拟机休眠，可能导致令牌发放异常（比如突然补发一堆）
- 测试时用
time.Sleep()模拟延迟容易误判——因为Wait()内部用的是time.Timer，而time.Sleep()不影响其行为
真正要压垮它的，往往不是算法，而是你把它和慢 DB 查询、长 GC 一起塞进 HTTP handler 里——限流该在入口处做完，别拖到业务逻辑里才检查。
