Go语言如何实现令牌桶限流器_Golang自定义rate limiter编写方法-Golang-PHP中文网

golang.org/x/time/rate.limiter本质是令牌桶，非漏桶或滑动窗口，采用原子计数器+单调时钟实现无锁、高精度、线程安全限流，95%场景无需自研；误用多源于未理解rate.every语义、混淆allow/reserve用途或错误使用wait。

go语言如何实现令牌桶限流器_golang自定义rate limiter编写方法

为什么直接用 `golang.org/x/time/rate` 的 `Limiter` 就够用了

Go 官方扩展库里的 rate.Limiter 本质就是令牌桶（token bucket），不是漏桶，也不是滑动窗口。它用一个原子计数器 + 系统单调时钟实现无锁限流，精度高、开销低、线程安全——95% 的场景下，你不需要自己重写。

常见误判是认为“官方实现不够灵活”，但实际踩坑多发生在：没理解 rate.Every 和底层填充逻辑、在高并发下误用 Allow 而非 Reserve、或把 Wait 用在非阻塞上下文里。

rate.NewLimiter(rate.Limit(100), 1) 表示每秒最多 100 个令牌，初始桶容量为 1（注意不是 100）
令牌填充是惰性的：调用 Reserve 时才按时间差补发，不依赖后台 goroutine
Allow 是非阻塞的布尔判断，适合快速失败；Wait 会阻塞直到拿到令牌，适合必须执行的请求

自定义令牌桶时最容易错的三个地方

如果你真要手写（比如需要带 TTL 的令牌、绑定用户 ID 的动态配额、或与 Redis 联动），以下三点几乎必踩：

用 time.Now() 而非 time.Now().UnixNano() 做时间戳计算 → 在纳秒级精度下，浮点误差会导致令牌数多算或少算
桶容量更新未加锁，多个 goroutine 同时 Take 可能导致负值（如桶剩 1 个，两个协程同时读到 1，都减 1，结果变 -1）
令牌生成逻辑写成定时 tick（time.Ticker）→ 高负载下 ticker 可能堆积、延迟、甚至被 GC 暂停，令牌发放不再平滑

正确做法是像官方那样：每次请求时，用当前时间减去上次填充时间，乘以速率，得到应补充数量，再和最大容量取 min。

如何让 `rate.Limiter` 支持 per-user 动态限流

官方 Limiter 本身不带 key 维度，但组合很简单：用 sync.Map 存不同用户的限流器实例，配合过期清理即可。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

关键不是存多少，而是怎么清理——别用定时器扫全量 map，而是在每次访问时检查最后使用时间，超时则尝试删除（用 LoadAndDelete 避免竞争）：

type UserLimiter struct {
    limiters sync.Map // map[string]*rate.Limiter
    lastUsed sync.Map // map[string]time.Time
}
<p>func (u <em>UserLimiter) Get(userID string, r rate.Limit) </em>rate.Limiter {
if lim, ok := u.limiters.Load(userID); ok {
u.lastUsed.Store(userID, time.Now())
return lim.(*rate.Limiter)
}
lim := rate.NewLimiter(r, int(r)) // 初始桶大小 = 速率
u.limiters.Store(userID, lim)
u.lastUsed.Store(userID, time.Now())
return lim
}
</p>

注意：不要在 Get 里做 time.Since + Delete，因为 sync.Map 的遍历成本高；真正清理可另起轻量 goroutine 定期扫描 lastUsed。