go标准库无严格令牌桶实现，rate.limiter是漏桶变体；需手写支持原子操作、定时填充、非阻塞获取的tokenbucket，注意单机局限与分布式场景下的同步问题。
Go标准库里没有现成的 TokenBucket 实现
Go 的 net/http 和 golang.org/x/time/rate 都不提供严格意义上的令牌桶（Token Bucket），后者其实是“漏桶”变体——rate.Limiter 底层用的是**固定窗口+允许突发的滑动逻辑**，它通过 reserveN 模拟令牌填充，但不维护显式桶容量和实时令牌数。真要按 RFC 2697 或经典定义实现带容量上限、独立填充速率、可透支（burst）的令牌桶，得自己写或选第三方库。
常见误判是把 rate.NewLimiter(10, 5) 当作“每秒10个令牌、桶容量5”的令牌桶——其实它是“平均10QPS、最多允许5次瞬时突发”，底层无真实令牌计数器，而是靠时间戳推算“最早能放行的时间”。这在多数限流场景够用，但若需精确控制桶状态（比如动态调速、跨goroutine观察剩余令牌、与外部系统同步桶水位），就得另起炉灶。
手写一个线程安全的 TokenBucket 结构体
核心要解决三个问题：原子更新令牌数、按间隔填充、支持并发获取。不用锁也能做，但 sync/atomic 对 int64 更稳妥——因为令牌数可能为负（表示欠费），且需避免 ABA 问题。
-
tokens字段存当前令牌数，初始为burst（最大容量） - 用
time.Timer或后台 goroutine 填充令牌：推荐每1/rate秒加 1 个，比单次加 delta 更易理解且避免浮点误差 -
Take方法需 CAS 循环：读当前值 → 判断是否 ≥1 → 原子减 1 → 成功则返回 true；失败则等待下次填充或直接拒绝 - 别用
float64存令牌数，浮点精度会导致长期运行后偏差累积（比如每 100ms 加 0.1 个，10 小时后可能少加几十个）
示例关键片段：
type TokenBucket struct {
tokens int64
burst int64
mu sync.RWMutex
}
func (tb *TokenBucket) Take() bool {
for {
t := atomic.LoadInt64(&tb.tokens)
if t tb.burst {
atomic.StoreInt64(&tb.tokens, tb.burst)
}
}
}()
}
在 HTTP 中间件里集成 TokenBucket 要注意请求生命周期
每个请求进来都调用 Take()，但得确保失败时及时返回 429，且不阻塞后续请求。别在中间件里用 time.Sleep 等令牌，那会拖垮整个 handler。
- 不要把
TokenBucket实例放在 handler 函数内——每次请求新建就失去限流意义 - 共享实例必须是包级变量或注入到
struct{ bucket *TokenBucket }中，且确保Take()调用是非阻塞的 - 如果用在反向代理或长连接场景（如 WebSocket 升级），需区分“连接级”和“请求级”限流：前者用一个桶，后者每个请求扣一次令牌
- 日志里记录
atomic.LoadInt64(&tb.tokens)可帮你诊断桶是否被撑爆或长期空转
简单中间件示意：
func RateLimitMiddleware(bucket *TokenBucket) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !bucket.Take() {
http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
}
生产环境慎用纯内存 TokenBucket 做分布式限流
单机 TokenBucket 在多实例部署下完全失效——10 台机器每台都按 100QPS 放行，实际就是 1000QPS。想跨进程同步桶状态，要么上 Redis（用 INCR+EXPIRE 模拟，但要注意 Lua 原子性），要么用集中式配额服务（如 Google Cloud Armor 或自研 quota server）。
即使只用单机，也得防住两类漏洞：
- 高频短连接攻击：TCP 握手后立刻发请求再断开，
Take()成功但连接不复用，桶被快速掏空——此时需结合连接数限制（net.Listener层）或 TLS Session ID 复用检测 - 桶初始化时机错误：如果
startFill()在 HTTP serverListenAndServe之后才启动，冷启动期间所有请求都会因桶为空被拒
真正难的不是写对一个桶，而是让它的行为在各种网络抖动、GC STW、时钟跳变下依然符合预期。比如填充 goroutine 被调度延迟 200ms，可能导致瞬间多放出 2 个令牌——这种边界情况得靠压测和监控暴露，代码里很难穷举。
