Go语言实现接口限流，Golang限流中间件实战

限流不能只靠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 实例：

// 示例：按 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()（需反射或封装）

限流不是加个中间件就完事，它的核心是「可控的拒绝」——拒绝谁、为什么拒绝、拒绝后能否追溯，这些比“怎么通过”更难做好。