golang.org/x/time/rate 是官方维护的轻量、无锁、并发安全令牌桶限流库，需复用实例而非每次新建，支持动态调速；http中间件中应优先用 reserven 配合上下文检查，避免误用 allow 或 wait 导致逻辑错误。
Go 里用 golang.org/x/time/rate 实现令牌桶限流
标准库没有原生限流器，但 golang.org/x/time/rate 是官方维护、生产可用的令牌桶实现。它轻量、无锁、支持动态调整速率，比自己手写 time.Ticker + channel 更可靠。
常见错误是直接在 HTTP handler 里 new 一个 rate.Limiter，导致每个请求都新建限流器，完全失效。正确做法是复用同一个实例，按用户 ID、IP 或路由路径做 key 分组管理。
-
rate.NewLimiter(rate.Limit(10), 5)表示：最大允许突发 5 个令牌，长期速率为每秒 10 个请求 - 第一个参数是
rate.Limit类型（本质是float64），不是整数；传10.0比10更明确 - 第二个参数是
burst，必须 ≥ 1；设为 1 就是严格匀速，设太大则失去限流意义 - 注意：该包不处理分布式场景，单机有效
HTTP 中间件里怎么安全调用 limiter.Wait
Wait 会阻塞直到拿到令牌或上下文超时，适合对延迟敏感度低、且希望“等一等再试”的场景；而 Allow 或 TryConsume 是非阻塞的，适合快速失败。
中间件里别直接用 limiter.Wait(r.Context()) —— 如果客户端断连或超时，r.Context() 可能已取消，Wait 会立即返回错误，但你可能没检查这个错误就继续执行了 handler，造成逻辑错乱。
立即学习“go语言免费学习笔记（深入）”；
- 务必检查
err：如果err == context.Canceled || err == context.DeadlineExceeded，说明请求本身已无效，不该再往下走 - 更稳妥的做法是用
limiter.ReserveN(r.Context(), 1)，它返回*rate.Reservation，可调用OK()判断是否成功，且支持预占多个令牌 - 别在
http.ServeHTTP外层 defer 调用Reservation.Cancel()—— 它只应在未使用该 reservation 时才调，否则可能误释放
如何给不同用户/路径配不同限流策略
硬编码一个全局 rate.Limiter 只适用于全站统一限流。真实场景中，登录用户和游客、VIP 和普通用户、/api/pay 和 /api/status 的容忍度完全不同。
典型做法是用 sync.Map 或带 TTL 的内存缓存（如 github.com/bluele/gcache）按 key 缓存 *rate.Limiter 实例，key 可以是 "ip:" + clientIP 或 "user:" + userID。
- 避免 key 泛滥：限制 key 总数，比如只对前 10 万 IP 做个性化限流，其余走默认策略
- 注意
rate.Limiter不是线程安全的？错，它是并发安全的，但SetLimitAndBurst是原子更新，可用于运行时动态调速 - 不要在每次请求里 new
rate.Limiter并丢弃——构造开销小，但 GC 压力会上升，尤其高 QPS 下 - 测试时用
limiter.SetLimitAndBurst(rate.Limit(1000), 1000)临时放开，别改代码注释
为什么 Allow 返回 true 还可能被拒绝
Allow 看起来最简单，但它只反映「此刻是否能拿一个令牌」，不保证后续操作一定成功。真正容易踩坑的是：它不感知上下文取消，也不阻塞等待，所以常被误用于需要强一致性的场景。
比如你在 Allow 返回 true 后去查数据库、发 MQ，结果 DB 挂了、MQ 超时——整个请求失败了，但令牌已被扣掉，用户白丢一次配额。
- 更适合的模式是：
ReserveN(ctx, 1)→ 检查OK()→ 执行业务 → 成功则CancelAt()不调用（自动消耗），失败则显式Cancel() -
Allow适合日志采样、指标上报这类“丢了也不关键”的操作 - 注意：所有方法都基于本地时钟，系统时间跳变（如 NTP 校准）会导致令牌生成节奏紊乱，生产环境确保
ntpd或chronyd稳定运行
令牌桶真正的复杂点不在代码几行，而在怎么定义“谁该被限”、什么时候该“重置桶”、以及下游服务挂了时要不要把令牌还回去——这些没法靠 rate.Limiter 自动解决。
