Golang实现Web请求限流技巧

net/http 默认不限流，因它仅负责连接处理与路由分发；限流须自行实现，推荐用 golang.org/x/time/rate 基于 IP 或路径构建多键令牌桶中间件，并注意超时控制、错误码透传与指标暴露。

为什么 net/http 默认不限流，而你必须自己加

Go 的 http.Server 本身不提供请求速率限制（rate limiting），它只负责接收连接、解析 HTTP 报文、分发到 handler。高并发下，一个恶意 IP 或突发流量就可能打满 CPU、耗尽 goroutine 或压垮下游服务。限流不是“可选优化”，而是生产环境的兜底防线。

常见误判是用 time.Sleep 或全局计数器硬拦——前者阻塞 goroutine，后者在多实例或高并发下失效。正确做法是使用带滑动窗口或令牌桶语义的中间件，且必须基于每个请求上下文做判断。

用 golang.org/x/time/rate 实现每秒请求数（QPS）限流

rate.Limiter 是 Go 官方维护的轻量级令牌桶实现，适合单机限流。它不依赖外部存储，内存开销低，精度为纳秒级，但注意：它无法跨进程共享状态。

• 初始化时指定 rate.Limit（如 10 表示每秒 10 个令牌）和桶容量（如 5，允许短时突发）
• 在 handler 中调用 limiter.AllowN(time.Now(), n) 判断是否允许处理 n 个请求；更常用的是 limiter.WaitN(ctx, 1)，自动阻塞等待令牌（适合需保序场景）
• 不要对每个请求都新建 rate.Limiter，应按维度（如 IP、API 路径）复用实例，否则 GC 压力大且失去限流意义

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 路径做动态限流，避免一刀切

全局限流会误伤正常用户；完全放行又失去意义。实际要区分对待：登录接口可宽松，支付回调必须严格，爬虫 IP 应直接拒绝。

推荐用 sync.Map + rate.Limiter 构建内存级多键限流器。Key 可以是 r.RemoteAddr（IP）、r.URL.Path 或两者组合。注意：sync.Map 不支持 TTL，需配合定时清理或用 LRU 策略控制 size。

• IP 限流：提取 r.Header.Get("X-Forwarded-For") 时需校验可信代理，否则易被伪造
• 路径限流：对 /api/v1/users/:id 这类带参数路由，应先正则提取基础路径，避免每个 ID 都生成新限流器
• 避免用 map[string]*rate.Limiter 配 sync.RWMutex —— 写多读少场景下锁争用严重，sync.Map 更合适

生产环境必须考虑的三个边界问题

限流逻辑上线后最常出问题的地方，往往不在算法本身，而在与真实链路的耦合细节。

• 超时控制：若用 WaitN(ctx, 1)，务必传入带 deadline 的 context.Context，否则慢限流器会拖住整个请求生命周期
• 错误码透传：Nginx 或 API 网关可能已做一层限流，Go 层返回 429 时，前端重试逻辑需识别并退避，不能和 500 混淆
• 指标暴露：用 prometheus 暴露 http_requests_total{status="429"} 和 rate_limiter_tokens_remaining，否则你根本不知道限流是否生效、谁在被拦

跨节点限流（如 Redis + Lua）或更细粒度的请求内容限流（如按 body 大小、特定 query 参数），属于另一层复杂度，单机 rate 包解决不了——别试图在一个包里塞所有需求。