真正的限流必须在入口做“允许/拒绝”决策且状态跨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 倍。