直接用 golang.org/x/time/rate.limiter，它并发安全、精度高、易集成；每个路由配独立实例，用 allow() 非阻塞判断，api 级与用户级限流需隔离且分层判定，禁用 wait() 防雪崩。
Go 限流中间件该用 golang.org/x/time/rate 还是自研令牌桶？
直接结论：用 rate.Limiter，别自己手写令牌桶逻辑。它已通过生产级压测，支持并发安全、精度可控（time.Now() 级别），且能无缝接入 http.Handler 链路。
常见错误是把 rate.NewLimiter 实例全局复用却忽略其状态共享问题——比如所有请求共用一个 rate.Limiter{r: 100, b: 50}，结果突发流量打满 b 后，后续请求全被拒，连预热都做不到。
- 每个服务/路由应配独立
rate.Limiter实例，按需初始化，例如：limiter := rate.NewLimiter(rate.Every(1*time.Second), 100) - 不要在中间件里反复调用
limiter.Reserve()再检查OK()；改用limiter.Allow()（轻量）或limiter.Wait(ctx)（需阻塞等待） - 注意
rate.Every(100 * time.Millisecond)表示“每 100ms 放行 1 个”，不是“每秒 10 个”——速率单位易错，建议统一用rate.Limit(float64(qps))显式表达
HTTP 中间件里怎么正确注入限流器而不污染 handler 逻辑？
核心是把限流判断提前到 http.ServeHTTP 最早可中断的位置，且不依赖任何业务上下文。典型错误是把限流逻辑塞进业务 handler 内部，导致失败响应体混入业务错误结构，或者 panic 后无法统一捕获。
正确做法是用闭包封装 http.Handler，在 ServeHTTP 入口做拦截：
立即学习“go语言免费学习笔记（深入）”；
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)
})
}
}- 务必在
next.ServeHTTP前完成限流判断，否则请求已进入下游，限流失去意义 - 不要在中间件里读取
r.Body或调用r.ParseForm()，会破坏 body 流，下游 handler 读不到数据 - 如果网关需按用户 ID 或 API Key 区分限流，必须从
r.Header或r.URL.Query()提取标识，然后查对应*rate.Limiter——别试图在Allow()前修改 limiter 实例，它是不可变的
微服务网关中多级限流（API 级 + 用户级）怎么避免嵌套判定失效？
两级限流不是简单套两个 Allow()，而是要明确优先级和状态隔离。常见坑是用户级限流器被 API 级共享，导致高活跃用户拖垮整个接口的配额。
正确结构是「API 级限流兜底 + 用户级限流细控」，两者独立计数：
- API 级：用固定
rate.Limiter控制总入口 QPS，例如/user/profile全局最多 500qps - 用户级：按
X-User-IDHeader 构建 map 缓存，每个 key 对应一个*rate.Limiter，生命周期与连接池无关，需加sync.Map或 LRU 清理（否则内存泄漏） - 判定顺序必须是先过 API 级，再过用户级；任一拒绝即返回
429，但响应头应标明触发层级，例如X-RateLimit-Reason: user_quota_exceeded - 注意 map 中的
*rate.Limiter实例不能复用——每次新建，否则不同用户的 token 池互相污染
为什么 rate.Limiter.Wait() 在网关里容易引发超时雪崩？
因为 Wait() 会阻塞 goroutine 直到有 token 可用，而网关通常设了短超时（如 3s），一旦后端延迟升高，大量请求在限流器上排队，耗尽可用 goroutine，新请求连限流判断都进不来。
真实线上环境几乎不用 Wait()，除非你明确控制了最大排队时间且有熔断兜底：
- 永远用
Allow()做非阻塞判断，失败立即返回，不排队 - 若真需要平滑削峰，改用带缓冲的 channel + 定时 refill，而非依赖
Wait()的内部 sleep - 监控指标必须包含
rate_limiter_rejected_total和rate_limiter_allowed_total，否则无法区分是攻击还是配置过严
最常被忽略的一点：限流器本身不感知下游健康状态。如果某个微服务实例已卡死，限流器照常放行请求，只是它们全在等超时——得配合主动探活或熔断器（如 sony/gobreaker）一起用，光靠流控解决不了雪崩。
