限流不能只靠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 实例：
立即学习“go语言免费学习笔记（深入）”；
// 示例：按 path + method 构建 key
key := fmt.Sprintf("%s:%s", r.Method, r.URL.Path)
limiter, _ := limiters.LoadOrStore(key, rate.NewLimiter(50, 100))
if !limiter.(*rate.Limiter).AllowN(time.Now(), 1) {
http.Error(w, "too many requests", http.StatusTooManyRequests)
return
}
这里几个关键点：
- 避免用
map[string]*rate.Limiter直接读写——并发访问会 panic，必须用sync.Map或第三方分片 map（如github.com/coocood/freecache） - 不要在每次请求里新建
rate.Limiter，初始化开销小但 GC 压力大；复用实例更稳 - 如果需要动态更新速率（比如运营后台调整），得用带原子更新能力的封装，原生
rate.Limiter不支持运行时改 limit/capacity
生产环境绕不开的三个坑
本地测通不等于线上可用。这三个问题高频出现，且容易被忽略：
- 时间精度漂移：
time.Now()在容器或虚拟机里可能跳变，导致令牌计算异常；建议用limiter.ReserveN+ 自定义时钟接口，或统一用 monotonic clock（Go 1.9+ 默认启用） - 内存泄漏：用
sync.Map存 limiter 时，若 key 持续增长（比如含 UUID 或时间戳的路径），map 不会自动清理——得加定时清理 goroutine 或用 LRU cache（如github.com/hashicorp/golang-lru） - 拒绝响应没埋点：只返回
StatusTooManyRequests但没记录 key、当前令牌数、拒绝原因，出问题时无法定位是规则写错还是攻击突增——至少记一条 structured log，包含limiter.CurTokens()（需反射或封装）
限流不是加个中间件就完事，它的核心是「可控的拒绝」——拒绝谁、为什么拒绝、拒绝后能否追溯，这些比“怎么通过”更难做好。
