直接用 golang.org/x/time/rate，它基于线程安全的令牌桶，支持突发流量且经生产验证；不支持分布式限流，跨实例需结合 Redis 或专用服务。
Go 限流选 golang.org/x/time/rate 还是自己写？
直接用 golang.org/x/time/rate，别自己造轮子。它基于令牌桶（token bucket），线程安全、内存开销低、支持突发流量，且已被大量生产服务验证。自己实现容易在并发场景下漏判或误限（比如未加锁的计数器、时钟漂移导致的桶重置异常）。
注意：它不支持分布式限流，单机有效；若需跨实例统一限流（如 API 网关），得配合 Redis + Lua（如 redis-cell 模块）或专用限流服务。
rate.Limiter 的三个关键参数怎么设？
初始化 rate.NewLimiter 时传入两个核心参数：limit rate.Limit（每秒令牌数）和 burst int（桶容量）。第三个参数是可选的 clock，一般不用动。
-
limit = 100表示长期平均速率 ≤ 100 QPS；但瞬时可能达到burst级别（比如burst = 200，允许短时 200 并发请求） -
burst必须 ≥ 1，且建议 ≥limit（否则桶太小，刚填充就耗尽，失去平滑作用） - 若想严格硬限流（不允许任何突发），设
burst = 1，但会显著降低用户体验——例如连续两次 HTTP 请求大概率第二次被拒
limiter := rate.NewLimiter(rate.Limit(50), 100) // 平均 50 QPS，最多容忍 100 次瞬时请求
HTTP 中间件里怎么正确调用 Wait 或 AllowN？
别在 handler 开头无脑 limiter.Wait(r.Context())——它会阻塞直到拿到令牌，对超时敏感的接口（如移动端心跳）可能拖垮整个请求链路。优先用非阻塞的 AllowN 做预检。
立即学习“go语言免费学习笔记（深入）”；
- 用
AllowN(time.Now(), n)判断能否立即执行n次操作（如单次请求算 1 次） - 返回
false时立刻返回http.StatusTooManyRequests，不进业务逻辑 - 注意时间戳必须用
time.Now()，不要复用旧时间，否则会导致令牌计算偏差
func rateLimitMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !limiter.AllowN(time.Now(), 1) {
http.Error(w, "too many requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
为什么压测时发现限流没生效？常见漏点
限流失效往往不是库的问题，而是使用姿势不对：
- 把
rate.Limiter声明在 handler 函数内 → 每次请求新建一个 limiter，完全没效果 - 在中间件里每次
http.Request都 new 一个 limiter → 同上，作用域错 - 没考虑不同路由/用户维度的差异化限流（如 /login 接口应比 /public/data 更宽松），而只用了全局单例 limiter
- 测试时用
curl串行发请求 → 实际并发不足，看不出限流效果；要用ab -n 1000 -c 200或hey -z 10s -q 50 -c 100
真正复杂的场景（按用户 ID 限流、分层限流、动态配额）需要封装自己的限流管理器，用 sync.Map 存不同 key 对应的 *rate.Limiter，并加 TTL 清理闲置条目——这点最容易被忽略，跑几天后 map 不释放会内存泄漏。
