限流中间件不能直接在handler里用time.sleep，因其阻塞goroutine导致并发串行化、吞吐暴跌，且无法控制qps；应使用rate.limiter等非阻塞模型，通过高阶函数封装allow()实现可复用、可配置的路径级限流。
限流中间件为什么不能直接在 handler 里写 time.Sleep？
因为 time.Sleep 阻塞的是整个 goroutine，而 HTTP handler 默认运行在独立 goroutine 中——看似“限流”，实则把并发压成串行，吞吐暴跌，还可能拖垮连接池。真正要限流的是请求速率（QPS），不是延迟响应。得用计数器或令牌桶这类非阻塞模型，且必须和 handler 生命周期解耦。
常见错误是把限流逻辑硬编码进业务 handler，导致复用性差、测试困难、无法组合。高阶函数的价值就在这里：它不侵入业务逻辑，只负责“套一层壳”。
怎么用高阶函数包装 handler 实现可配置的限流？
核心思路是写一个函数，输入是原始 http.HandlerFunc 和限流参数，输出是新的 http.HandlerFunc。限流逻辑本身交给现成库（比如 golang.org/x/time/rate），高阶函数只做“粘合”和“透传”。
-
rate.NewLimiter创建限流器，注意第一个参数是rate.Limit（每秒允许请求数），第二个是最大突发量（burst）——burst 太小会导致合法突增被拒，太大等于没限 - 限流器必须复用，不能每次 handler 调用都新建；建议作为闭包变量或结构体字段持有
- 检查限流失败时，用
w.WriteHeader(http.StatusTooManyRequests)+ 显式返回，避免后续逻辑执行
示例：
func NewRateLimitMiddleware(limiter *rate.Limiter) func(http.HandlerFunc) http.HandlerFunc {
return func(next http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
w.WriteHeader(http.StatusTooManyRequests)
w.Write([]byte("too many requests"))
return
}
next(w, r)
}
}
}
为什么推荐用 Allow() 而不是 Wait()？
Wait() 会阻塞直到拿到令牌，对 Web 场景不友好——用户等待不可控，超时难管理，还可能触发客户端重试放大压力。Allow() 是即时判断，0 延迟，失败立刻响应，更符合 REST 接口语义。
如果真需要平滑削峰（比如后台任务），才考虑 WaitN(ctx, n)，但必须配 context.WithTimeout，否则 goroutine 泄漏风险极高。
-
Allow()返回bool，语义清晰，易测试 -
Wait()返回error，且隐含调度等待，HTTP handler 里基本不用 - 注意：
Allow()不是原子计数器——它底层基于time.Now()计算窗口，高并发下可能略微超发，但对大多数 API 已足够
如何让限流中间件支持路径粒度和动态配置？
硬编码一个全局限流器不够灵活。真实场景常需：/api/pay 限 10 QPS，/api/status 限 100 QPS，甚至按用户 ID 动态计算配额。这时高阶函数得升级为工厂函数 + 路由匹配逻辑。
- 用
r.URL.Path或chi.RouteContext(r.Context()).RoutePattern()提取路径，查 map 得对应限流器 - 避免在每次请求里做字符串 map 查找——提前编译正则或用 trie 树索引路径前缀
- 动态配额（如按
r.Header.Get("X-User-ID")）务必加缓存（sync.Map），并设 TTL，防内存泄漏 - 别把限流器存在
context里传递——它不是请求级数据，而是策略实例
关键点：高阶函数只是入口，真正的复杂度在限流策略的组织方式。越细的控制粒度，越要小心锁竞争和内存占用。
路径匹配和配额计算这两块最容易在线上突然变慢，上线前务必用 go tool pprof 抓 CPU 火焰图确认无热点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
