用 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、微服务接口几乎全是令牌桶的天下。
立即学习“go语言免费学习笔记（深入）”；
- 用
time.Ticker自建漏桶，必须配select{case + 超时控制，否则 <code>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)精确推进时间
限流的边界感特别强：桶大小、速率、初始值、是否允许突发，差一点就会压垮下游或误伤合法用户。所有配置项都得从配置中心或环境变量注入，别硬编码。
