go语言标准库不内置漏桶或令牌桶，但golang.org/x/time/rate的rate.limiter是生产级令牌桶实现，基于惰性计算、原子操作和单调时钟，线程安全且高精度；手写易出错，应优先复用该包，burst至少为1，http中间件中需复用实例而非每次新建。
Go 语言本身不内置漏桶（leaky bucket）或令牌桶（token bucket）限流器，但标准库 golang.org/x/time/rate 提供了生产级的 rate.Limiter，它底层是**基于令牌桶算法实现的**，且已针对并发、精度、重置逻辑做了充分优化。直接手写这两种算法不仅容易出错，还会绕过 Go 对 ticker、原子操作和上下文取消的成熟抽象。
为什么不要自己实现漏桶算法
漏桶在 Go 中常被误认为“用 channel + ticker 模拟水滴匀速流出”，但这种实现存在几个硬伤：
- 无法精确控制单次请求的“水量”（比如不同 API 权重不同），
rate.Limiter支持Limit.ReserveN和带权重的AllowN，而 channel 方案只能粗粒度阻塞 - 漏桶要求严格 FIFO，但 Go 的 channel 在高并发下无法保证调度顺序；真实场景中，更需要的是“允许突发 + 平滑长期速率”，这正是令牌桶的优势
- 手动管理
time.Ticker容易泄漏 goroutine，尤其在限流器生命周期短于服务时；rate.Limiter无 ticker，靠time.Now()+ 原子计数实现零开销
如何正确使用 rate.Limiter 实现令牌桶
rate.Limiter 默认就是令牌桶：每秒向桶中添加 r 个令牌，每次请求消耗 1 个（或 n 个），桶容量为 b。关键参数不是“桶大小”和“漏水速度”，而是 rate.Limit 和 burst：
-
rate.NewLimiter(rate.Every(200*time.Millisecond), 5)表示：每 200ms 补 1 个令牌（即 QPS=5），桶最大容量 5 —— 等价于“5QPS + 最多允许 5 次瞬时突发” - 调用
limiter.Allow()是非阻塞判断，limiter.Wait(ctx)会阻塞直到拿到令牌，limiter.Reserve()返回一个*rate.Reservation，可检查是否能立即执行、延迟多久执行 - 注意：
burst必须 ≥ 1，且不能设得过大（比如 10000），否则内存占用低但突发流量可能压垮下游，这不是算法问题，而是业务容量设计问题
漏桶语义怎么用令牌桶模拟
严格意义上的漏桶（恒定输出速率，不支持突发）在现实中极少单独使用。若你确实需要“强制削峰、不允许任何突发”，可通过以下方式逼近：
- 将
burst设为 1，rate设为你期望的稳定 QPS，例如rate.NewLimiter(rate.Every(100*time.Millisecond), 1)→ 每 100ms 最多放行 1 个请求 - 配合
limiter.Reserve().Delay()计算等待时间，再用time.Sleep主动延迟（注意：这会阻塞 goroutine，不如让客户端重试或返回 429） - 真正需要“漏桶语义”的场景（如硬件网卡限速），应交给基础设施层（iptables、nginx limit_req）处理，Go 层保持轻量
常见错误与兼容性陷阱
很多人掉进这些坑里：
- 用
time.Sleep模拟漏桶：会导致 goroutine 阻塞，goroutine 数暴涨，OOM 风险远高于限流收益 - 把
rate.Limit误当成“每秒令牌数”，实际它是“每秒补充多少个令牌”，单位是float64，支持0.5这样的值（即每 2 秒 1 个） - 在 HTTP handler 中反复创建新
rate.Limiter实例：每个实例都独立计数，起不到全局限流作用；应定义为包级变量或按 key 分组复用 - 忽略上下文取消：
limiter.Wait(ctx)会在 ctx 被 cancel 时立即返回 error，但Allow()不感知 ctx —— 别混用
真正复杂的点不在算法选择，而在如何把 rate.Limiter 绑定到具体维度：是 per-IP、per-user-token、还是 per-endpoint？以及失败时该返回 429、降级，还是丢弃请求？这些决策比“用漏桶还是令牌桶”重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
