time.ticker不能直接用于令牌桶实现，因其基于系统时钟的固定周期触发，无法按需精确补发令牌，导致限流窗口漂移、瞬时超限；可靠实现需每次请求时根据时间戳动态计算应补充令牌数，并用float64存储防误差累积。
为什么 time.Ticker 不能直接用在令牌桶实现里
很多人一上来就想用 time.Ticker 每秒往桶里“放一个令牌”，看似简单，但会出问题：time.Ticker 是基于系统时钟的周期性触发，无法响应突发请求的精度需求；当请求间隔小于 tick 周期（比如 50ms 内来了 3 个请求），它只能按固定节奏补发，导致实际限流窗口漂移、瞬时超限或漏放。
真正可靠的令牌桶必须支持「按需计算」——每次请求来时，根据上一次取令牌的时间戳，算出该补多少令牌。Go 标准库没直接提供，得自己维护状态。
- 核心是记录上次请求时间
last和当前令牌数tokens - 每次调用前先调用
updateTokens()：用time.Since(last)算出经过时间，乘以速率得到应补充量 - 注意浮点运算误差累积，建议用
float64存储令牌，上限截断为cap
golang.org/x/time/rate.Limiter 能直接用，但要注意它的默认行为
标准扩展包里的 rate.Limiter 就是基于令牌桶的实现，封装了上面那些细节，但默认配置容易让人误判效果。
- 创建时
rate.NewLimiter(rate.Limit(10), 10)表示“每秒 10 个令牌，桶容量 10”——不是“最多并发 10”，而是“允许突发最多 10 个请求，之后严格匀速” - 它默认使用
time.Now()计算令牌，所以高并发下多个 goroutine 同时调用Allow()不会互相阻塞，但Wait()会主动 sleep，适合后端 API 接口 - 如果用
Reserve()手动控制等待逻辑，要注意返回的*rate.Reservation必须调用OK()或Cancel()，否则可能泄漏定时器资源
HTTP 中间件里怎么嵌入限流，又不拖慢正常请求
限流逻辑必须轻量，不能在每次请求都新建对象或锁全局状态。常见错误是每个请求 new 一个 rate.Limiter，或者用 map + mutex 存不同路径的限流器但没做 key 归一化。
- 按路由路径限流？用
sync.Map缓存*rate.Limiter，key 是处理过的 path（比如去掉 query 参数、统一 trailing slash） - 避免锁竞争：初始化时预热常用路径的限流器，读多写少场景下
sync.Map.LoadOrStore比全局 mutex 更高效 - 别在中间件里调用
limiter.Wait()—— 它会阻塞当前 goroutine；改用if !limiter.Allow() { http.Error(w, "too many requests", http.StatusTooManyRequests); return } - 记录被限流次数时，用
atomic.AddInt64，别用普通 int 变量加锁
测试限流是否生效，光看日志不够
本地跑几个 curl 看返回码，很容易漏掉边界情况：比如桶刚满时连续请求、跨秒瞬间的令牌补给、或低频长连接下的令牌衰减。
- 写单元测试时，用
rate.NewLimiter(1, 1)+clock := &manualClock{}（自定义实现time.Time的 mock 时钟），能精确控制“过了多久”，验证补令牌逻辑 - 压测时不要只用
ab或hey的 -n 参数，要配合 -c 控制并发数，并观察服务端http.StatusTooManyRequests的真实比例是否符合预期速率 - 注意 Go runtime 的 GC 暂停会影响
time.Now()精度，在高负载下可能导致令牌计算偏少，生产环境建议用runtime.nanotime()做辅助校准（但rate.Limiter内部已处理过这类问题，一般不用动）
令牌桶真正的复杂点不在算法本身，而在于和真实请求生命周期的耦合：什么时候更新时间戳、要不要阻塞、如何复用限流器、以及怎么让测试覆盖到时钟跳变和并发争抢——这些地方不细想，上线后流量一抖就露馅。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
