Go rate.Limiter：用令牌桶把入口流量变成可承受的速度

限流不是为了拒绝用户，而是为了保护系统在高峰期仍然可用。x/time/rate 提供的令牌桶可以同时表达平均速率和突发容量，适合大多数 Go 服务入口限流。

Allow 适合快速拒绝

Allow 不阻塞，拿不到令牌就返回 false，适合 API 网关、写接口和明确要求快速失败的场景。

Wait 适合短暂排队

Wait 会等待令牌，但必须传入 context，避免无限排队。对于用户请求，排队时间不能超过接口总预算。

按用户或租户分桶

全局限流只能保护实例，不能阻止单个用户占满配额。更常见的做法是按用户、IP 或租户维护 limiter，并给 limiter 加过期清理。

生产场景

适用于开放 API、登录短信、支付回调、爬虫易触达页面和内部高成本接口。限流的关键是保护系统可用性，而不是简单拒绝流量。

关键指标

• 429 数量与总请求量比例
• 令牌桶等待时间和被拒绝请求分布
• 限流启用后 5xx、P99 和下游错误是否下降

常见误区

• 只有实例级限流，无法约束单个租户或 IP
• Burst 设置过大，短时间仍能打满下游
• Wait 没有 context，排队时间超过用户可接受范围

落地建议

建议按接口成本分级限流，高成本写接口优先快速拒绝，低成本读接口可短暂排队。多租户系统应把用户、租户或 IP 作为 limiter key，并定期清理空闲 limiter。

代码示例

limiter := rate.NewLimiter(rate.Limit(100), 200)

func middleware(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)
    })
}

上线检查

• 限流返回明确的 429。
• Burst 不能大到压垮下游。
• 按用户维度清理长时间不用的 limiter。