真正的限流必须在入口做“允许/拒绝”决策且状态跨goroutine共享；推荐用golang.org/x/time/rate实现令牌桶

中间件，按IP或API Key差异化限流，并注意初始化、熔断和监控。

为什么 http.HandlerFunc 里直接用 time.Sleep 不能算限流

它只是延迟响应，不拒绝超额请求，QPS 依然会冲垮后端。真正的限流必须在入口做“允许/拒绝”二选一决策，且状态要能跨 goroutine 共享。常见错误是把计数器设成局部变量或没加锁，导致并发下计数失真。

实操建议：

立即学习“go语言免费学习笔记（深入）”；

• 限流逻辑必须包裹在中间件中，作用于所有或指定路由
• 计数器需用 sync.RWMutex 或原子操作（atomic.Int64）保护
• 避免用 time.Now().Unix() 做窗口切分——精度低、易受系统时间跳变影响
• 推荐用滑动窗口或令牌桶，而非固定窗口（后者有脉冲问题）

用 golang.org/x/time/rate 实现令牌桶中间件

这是 Go 官方维护的限流库，轻量、线程安全、支持突发流量。核心是 rate.Limiter，它内部用原子操作管理令牌，不需要手动加锁。

实操建议：

立即学习“go语言免费学习笔记（深入）”；

• 每个路由或每组路由应持有独立的 *rate.Limiter 实例，避免共享瓶颈
• 初始化时用 rate.NewLimiter(rate.Every(100*time.Millisecond), 5) 表示“每 100ms 最多放行 5 个请求”
• 在中间件中调用 limiter.Allow() 判断是否放行；返回 false 时立即写入 http.StatusTooManyRequests
• 注意：如果用 limiter.Wait(ctx)，会阻塞等待令牌，适合后台任务，但 Web 接口一般不推荐——用户不该等

简短示例：

func RateLimitMiddleware(limiter *rate.Limiter) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            if !limiter.Allow() {
                http.Error(w, "too many requests", http.StatusTooManyRequests)
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

如何按 IP 或 API Key 做差异化限流

全局统一限流太粗暴。真实场景需要识别来源（如 r.RemoteAddr 或 r.Header.Get("X-API-Key")），为不同主体分配独立限流器。

实操建议：

立即学习“go语言免费学习笔记（深入）”；

• 用 sync.Map 缓存每个 key 对应的 *rate.Limiter，避免重复创建
• 设置过期机制：给每个 limiter 关联最后访问时间，定时清理长期不用的条目（可用 time.Ticker + 单独 goroutine）
• 注意 r.RemoteAddr 可能是反向代理后的内网地址，优先取 X-Forwarded-For 并校验可信代理列表
• API Key 场景下，务必先完成鉴权再限流，否则攻击者可绕过

生产环境必须处理的三个细节

本地跑通不等于线上可用。这三个点最容易被忽略，但一出问题就是雪崩前兆。

• 限流器初始化不能放在 handler 内部——会导致每次请求新建一个 limiter，完全失效
• 没有熔断兜底：当下游服务延迟飙升时，限流器还在不断放请求过去，应结合 context.WithTimeout 控制单次请求生命周期
• 监控缺失：至少暴露当前各 key 的剩余令牌数（可通过 Prometheus 指标或 /debug/vars），否则无法判断策略是否生效

复杂点在于，限流不是加个中间件就完事；它是和部署拓扑、下游容量、业务 SLA 绑定的动态策略。同一个接口，在灰度环境和生产环境的阈值可能差 10 倍。