leakybucket结构体需包含capacity、rate、water、lastleaktime字段及sync.mutex，确保并发安全；allow()中用time.since()精确计算漏水量并加锁保护状态更新。
LeakyBucket结构体怎么设计才支持并发安全
Go里漏桶必须用互斥锁或原子操作保护核心字段，否则高并发下water（当前水量）和lastLeakTime（上次漏水时间）会错乱。别用全局变量存状态，每个限流器实例应独立持有自己的桶。
推荐结构体字段：容量capacity int64、漏水速率rate float64（单位：token/秒）、当前水量water int64、上次漏水时间lastLeakTime time.Time，再加一个sync.Mutex。注意rate用float64而非int，否则无法表达每秒0.1个token这种低频场景。
常见错误是把time.Now()直接塞进结构体初始化——这会让所有实例共享同一个初始时间戳，导致首次调用Allow()时误判漏水量。正确做法是在Allow()中按需计算流逝时间。
Allow()方法里如何精确计算漏水量
关键不是“每秒漏多少”，而是“从上次调用到现在该漏多少”。公式是：leaked := rate * (now.Sub(lastLeakTime).Seconds())，然后向下取整为int64。但要注意浮点误差累积，建议用time.Since()配合纳秒级计算再转秒数，避免多次调用time.Now()引入偏差。
实操要点：
- 先
mu.Lock()，再读lastLeakTime和water - 用
now := time.Now()统一获取当前时间，避免两次调用产生微小偏移 - 漏水量不能超过当前
water，所以water = max(0, water - leaked) - 更新
lastLeakTime = now，再判断water + 1 决定是否允许请求 - 如果允许，
water++并返回true；否则返回false
为什么不用time.Ticker实现定时漏水
用time.Ticker主动滴水看似直观，但实际会放大误差、浪费goroutine、且难以应对突发流量。漏桶本质是“请求驱动”的——只有来请求时才检查该漏多少，而不是维持一个后台滴水节奏。
一款AI视频创作工具，主要用于蛙蛙写作辅助AI写文，帮助获取创意灵感，提供拆书、小说转剧本、视频生成等功能，是一款功能全面的AI智能写作工具，适合需要提升相关任务效率的用户。
典型问题：
-
Ticker间隔设为100ms，但某次系统卡顿导致tick延迟200ms，那本该漏2次的水只漏了1次，桶就虚高了 - 每个
LeakyBucket启一个goroutine，1000个桶就是1000个goroutine，调度开销大 - 无法精确响应单个请求的时序，比如两个请求间隔80ms，按ticker逻辑可能都算在同一个100ms周期内，漏水量计算失真
真正的漏桶是惰性计算的，Allow()里那一行leaked := int64(rate * now.Sub(lastLeakTime).Seconds())才是核心。
如何测试LeakyBucket在边界条件下的行为
重点测三类场景：瞬间打满桶、长时间空闲后突袭、刚好卡在漏完临界点。别只写“调用10次返回true”这种弱测试。
实操建议：
- 用
time.Now().Add(-time.Second)伪造过去的时间戳，快速验证长时间未调用时的漏水量是否归零 - 构造两个请求，时间差设为
time.Second / rate，确认第二次调用恰好能通过（即漏掉1个token） - 在
Allow()里加defer mu.Unlock()前插入time.Sleep(10 * time.Millisecond)，模拟锁竞争，看并发调用是否仍保持总量不超限 - 把
rate设为0.5，请求间隔设为1999ms，检查是否稳定每2秒放行1个——这是浮点精度和时间截断最容易出错的地方
漏桶最难缠的不是逻辑，是时间精度、浮点舍入、并发读写这三者的组合效应。哪怕rate只差0.0001，跑一小时也可能偏移1~2个token。
