Golang限流模式：令牌桶与漏桶算法详解

用 golang.org/x/time/rate 实现令牌桶限流最稳妥

标准库不带限流，但官方维护的 rate 包就是为这设计的——不是玩具，生产可用。它底层是精确的令牌桶（token bucket），支持突发流量、可动态调整速率，且无锁（基于 time.Now() 和原子操作）。

常见错误是手动实现计数器+时间窗口，结果在高并发下漏判或误限——比如用 map + sync.Mutex 存每个 IP 的最后请求时间，既慢又难保证一致性。

• rate.NewLimiter(rate.Limit(10), 5)：每秒最多 10 次，初始桶容量 5（允许短时突发）
• 调用 limiter.Allow() 判断是否放行；更推荐 limiter.Wait(ctx)，自动阻塞等待令牌，适合 HTTP handler
• 注意 rate.Limit 类型是 float64，传整数要显式转成 rate.Every(100 * time.Millisecond) 或直接写 10.0
• 不要复用同一个 *rate.Limiter 给不同用户/租户——它没上下文隔离。按需创建，或用 sync.Map 缓存 per-key limiter（key 如 userID）

漏桶限流在 Go 里得自己搭，但通常没必要

漏桶本质是强制匀速输出，Go 生态没有开箱即用的漏桶实现。有人用 time.Ticker + channel 模拟，但会卡住 goroutine、难以取消、无法响应突发——和令牌桶解决的问题根本不同。

真实场景里，漏桶只在极少数地方有优势：比如硬件网关做硬 QoS，或日志投递要求严格平滑。Web API、微服务接口几乎全是令牌桶的天下。

• 用 time.Ticker 自建漏桶，必须配 select{case <-ticker.C: ...} + 超时控制，否则 Wait() 可能永久挂起
• golang.org/x/time/rate 的 Reserve() 方法返回 *rate.Reservation，能查剩余等待时间，已接近漏桶语义，别重复造轮子
• 如果你真需要漏桶行为，优先考虑前置反向代理（如 Nginx 的 limit_req）而不是在 Go 应用层做

HTTP 中间件里嵌限流，别碰 http.ResponseWriter 的 WriteHeader

限流逻辑必须在读取请求体之前、写响应头之后完成判断。很多人在中间件里先 w.WriteHeader(429) 再 return，结果下游 handler 还可能再写一次 header，触发 http: multiple response.WriteHeader calls 错误。

• 正确姿势：用 limiter.Wait(r.Context()) 拦截，失败就立即 http.Error(w, "Too Many Requests", http.StatusTooManyRequests) 并 return
• 别在限流后还让请求继续走完整 handler 链——除非你明确要做“记录但不限制”，那得用 limiter.Reserve() 查状态，而非 Allow()
• 路径级限流（如只限 /api/pay）记得用 r.URL.Path 做前缀匹配，别依赖 r.RequestURI（含 query 参数，易被绕过）

测试限流逻辑时，time.Now() 必须 mock

直接跑单元测试会发现 rate.Limiter 行为不可控：一秒内发 20 次请求，结果有时放过 12 次、有时 15 次——因为测试机时间精度和调度延迟不一致。

• 用 rate.NewLimiter 第三个参数传入自定义时钟：它接受 func() time.Time，测试时喂一个可进跳的 fake clock
• 社区常用 github.com/benbjohnson/clock，初始化 clk := clock.NewMock()，然后 rate.NewLimiter(..., clk.Now)
• 别用 time.Sleep 等待令牌生成——测试变慢、不稳定。用 clk.Add(1 * time.Second) 精确推进时间

限流的边界感特别强：桶大小、速率、初始值、是否允许突发，差一点就会压垮下游或误伤合法用户。所有配置项都得从配置中心或环境变量注入，别硬编码。