Go语言实现简单的协程令牌桶：语言学习中的流量整形-Golang-PHP中文网

time.ticker 不适合做令牌桶底层计时器，因其存在累积误差且无法按需补满令牌；应改用 time.since() 动态计算增量，并配合锁保护状态；阻塞式 take() 需结合 waiters 队列与 context 超时控制。

go语言实现简单的协程令牌桶：语言学习中的流量整形

为什么 `time.Ticker` 不适合做令牌桶的底层计时器

直接用 time.Ticker 每隔固定时间往桶里加一个令牌，看似简洁，但会累积误差——尤其在系统负载高、GC 频繁或协程调度延迟时，Ticker 的实际触发间隔可能明显偏离设定值。更严重的是，它无法处理「突发流量后快速恢复」的需求：比如桶空了，你希望 100ms 后补满 10 个令牌，而不是等下一个整点 tick 才加 1 个。

真正可控的方式是按需计算「上次填充到现在该补多少」，也就是用 time.Since() + 状态快照。这要求把「最后更新时间」和「当前令牌数」一起维护，且所有读写必须原子或加锁。

不要用 time.Ticker 驱动填充逻辑，除非你能接受 ±50ms 级别的漂移
每次 Take() 前先调用内部 refill()，基于 time.Now() 算增量
如果并发高，用 sync.Mutex 比 atomic 更稳妥——令牌数不是整数累加，还涉及浮点换算（如每秒 2.5 个），atomic 不好直接用

如何让 `Take()` 支持阻塞等待与超时返回

很多初学者只实现「有令牌就拿，没有就返回 false」，但这在真实服务中不够用：比如下游限流为 10 QPS，你希望上游请求排队等待，而不是瞬间打崩它。Go 的协程天然适合做这件事——关键在于别用忙等，而是用 chan struct{} + select。

典型结构是维护一个 waiters 队列（[]chan bool），当 Take() 发现令牌不足时，把当前 goroutine 的通知 channel 塞进去；而每次成功 refill 后，从队列头取出若干 channel 并发信号。注意要避免竞态：所有对 waiters 的操作必须在锁内完成。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

阻塞版 Take() 接收 context.Context，超时后自动从 waiters 中移除自己（需加锁遍历）
不要在锁内直接 close(ch) 或 ch ，先 unlock 再发信号，否则可能死锁
如果允许「最多等待 N 个令牌」，可在 waiter 结构体里存期望数量，而非只存 channel

`rate.Limiter` 能不能直接拿来用？什么情况下不该抄它的轮子

标准库 golang.org/x/time/rate 的 rate.Limiter 就是生产级令牌桶，支持 Allow()、Reserve()、Wait()，底层用 time.Now() + 精确浮点计算，还做了 burst 优化。90% 场景下，你应该直接用它，而不是手写。

只有两个合理例外：一是教学，想看清令牌如何随时间线性增长、如何处理边界（比如 burst=0 或 limit=0）；二是极端性能敏感场景（如每秒百万次判断），且你确认自己的简化版不带 context 取消、不支持 reserve 预占、不记录 last time —— 这时可去掉泛型和接口，硬编码 float64 计算，省掉一次 interface{} 转换。

线上服务优先用 rate.NewLimiter()，别因“想练手”在关键路径上自己造
如果你发现 rate.Limiter.WaitN() 在高并发下卡住，大概率是没配好 burst，而不是它本身有问题
手写时最容易漏的是「负令牌数」处理：补令牌前要先 clamp 当前值到 0，否则 tokens = min(tokens + delta, capacity) 会出错

协程泄漏风险：谁负责关闭等待队列里的 goroutine

当你用 channel 等待令牌时，goroutine 会阻塞在 select 上。如果限流器被丢弃（比如 HTTP handler 返回后忘记清理），而还有 goroutine 卡在 waiters 里，它们就永远无法唤醒——既不执行也不退出，形成 goroutine 泄漏。

解决办法不是“加个 Close() 方法遍历 close 所有 channel”，因为 channel 关闭后接收方仍会立即返回 false，无法区分是超时还是被取消。真正可靠的做法是：每个 waiter 绑定一个 context.Context，并在限流器内部启动一个监控 goroutine，监听该 context 的 Done；一旦收到 cancel，就从 waiters 中安全移除对应项（加锁 + 遍历指针比较）。