限流不能只靠time.Sleep，因其阻塞goroutine、无法区分请求来源与权重；应使用令牌桶（如rate.Limiter），按路径/方法分桶复用实例，并注意时间精度、内存泄漏和拒绝埋点。
限流为什么不能只靠 time.Sleep
直接在 HTTP handler 里用 time.Sleep 模拟“匀速放行”，看似简单，实则破坏了并发模型：它阻塞 goroutine，浪费调度资源，且无法区分请求来源、路径或权重。真实场景下，你得支持每秒 100 次调用、单 IP 每分钟 60 次、关键接口优先通行——这些都要求状态可维护、策略可配置、拒绝可观测。
令牌桶 vs 漏桶：Go 里该选哪个
Go 标准库 golang.org/x/time/rate 提供的是基于令牌桶（rate.Limiter）的实现，它更贴合“突发允许 + 平滑限制”的常见需求。漏桶逻辑上等价但实现更重（需显式维护队列），而令牌桶只需原子更新一个计数器，对高并发更友好。
使用时注意三点：
-
rate.NewLimiter的第一个参数是rate.Limit（如100表示每秒 100 个令牌），第二个是桶容量（如200），容量越大，越能容忍突发 - 调用
limiter.AllowN判断是否可通过，传入当前时间与期望令牌数；别用WaitN，它会阻塞，中间件里应快速失败 - 令牌桶不自动感知请求来源，IP 或用户 ID 需自行提取并做 map 分桶，但 map 非并发安全——得配
sync.Map或按 key 分片加锁
HTTP 中间件里怎么挂载限流逻辑
典型错误是把一个全局 rate.Limiter 实例用于所有请求，结果所有路径共用同一桶，完全失去路由级控制。正确做法是按路径、方法甚至 header 组合生成限流 key，再查缓存的 limiter 实例：
