应优先使用 golang.org/x/time/rate 的 Reserve 或 Wait，因其支持纳秒精度、突发容忍与上下文取消；避免 time.Sleep（阻塞 goroutine 降 QPS）、误用局部 channel（限流失效）、遗漏 ticker stop/once（goroutine 泄漏）。
Go 里自己手写漏桶限流，90% 的情况不如直接用 golang.org/x/time/rate 的 Reserve 或 Wait 配合自定义时间逻辑——它底层已支持纳秒级精度、突发容忍和上下文取消，而纯漏桶语义（严格匀速）在应用层实现成本高、易出错、难运维。
为什么别用 time.Sleep 实现漏桶
time.Sleep 会阻塞当前 goroutine，而 HTTP handler 每请求启一个 goroutine；一旦在中间件里调用 time.Sleep(100 * time.Millisecond)，等于把并发压成串行，QPS 直接归零。漏桶要的是“后台匀速发令牌”，不是“每个请求等一等”。
- 真正该用的是
time.Ticker：非阻塞、周期稳定、可配合select做非阻塞取令牌 - 必须配
stopCh和sync.Once，否则服务 reload 或配置热更时，ticker goroutine 泄漏，内存缓慢上涨 - 漏桶的“桶大小”靠 channel 容量控制，比如
make(chan struct{}, 5)表示最多积压 5 个令牌，溢出即丢——这和漏桶“溢出即弃”语义一致
漏桶实例必须全局共享，不能闭包私有
常见错误是把令牌 channel 写成中间件闭包里的局部变量：func(limitRate float64) http.Handler { tokens := make(chan struct{}, burst) ... }。结果每个中间件实例都新建一套 channel，完全不共享状态，限流失效。
- 正确做法：漏桶结构体字段含
tokens chan struct{}、stopCh chan struct{}、once sync.Once - 初始化只做一次：
once.Do(func() { go tickerLoop() })，tickerLoop中用select { case - HTTP 中间件中只引用已初始化好的实例，例如
var payBucket = NewLeakyBucket(10, 5)，然后在 handler 里select { case
拒绝响应必须早于任何 WriteHeader
很多人在中间件里先调 w.WriteHeader(429) 再 return，但下游 handler 可能仍会调 w.WriteHeader(200)，触发 http: multiple response.WriteHeader calls panic。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 限流判断必须放在读取请求体之前、任何响应写入之前
- 标准姿势是：
if !tryAcquireToken(bucket) { http.Error(w, "Too Many Requests", http.StatusTooManyRequests); w.Header().Set("Retry-After", "1"); return } - 务必设置
Retry-After头，前端才能退避；不设等于让客户端盲目重试，放大冲击
漏桶 vs 令牌桶：你真需要严格匀速吗
漏桶对突发流量零容忍，API 延迟稍高（比如 DB 慢查询），就会导致令牌被“积压消耗”，实际吞吐远低于配置值。而 rate.Limiter 的 ReserveN 调用 reservation.Delay() 后再 reservation.Fulfill()，行为已非常接近漏桶，且自带上下文取消、纳秒精度、burst 容量控制。
- 如果你的场景是保护下游稳定性（如调第三方支付接口），且能接受短时突增，优先用
rate.NewLimiter(10, 10)+Wait - 如果业务明确要求“每 100ms 最多处理 1 个请求”，且不允许任何偏差，才考虑自建漏桶，但必须 mock
time.Now才能可靠测试 - 生产环境更推荐前置 Nginx 的
limit_req，比 Go 应用层漏桶更轻量、更稳定、更易观测
漏桶最难的不是“怎么填水”，而是“怎么确保所有请求看到的是同一个桶、同一套时间、同一个退出信号”。一旦漏掉 stopCh 或共享机制，问题会在服务运行数天后才暴露——那时你得翻日志查 goroutine 数量，而不是看限流逻辑本身。
