Go 推荐用 golang.org/x/time/rate.Limiter 实现令牌桶限流因其轻量、线程安全、支持突发控制需复用实例、合理设置 rate 和 burst如 rate.Every(100ms), burst20并在路由前统一拦截避免误用 Allow() 或 per-request 新建。Go 用 golang.org/x/time/rate 做令牌桶限流最稳妥标准库没限流但官方扩展包 rate.Limiter 就是为这个场景设计的——轻量、线程安全、支持突发流量控制。别自己手写计数器或用第三方轮子除非你明确要绕过它的精度/阻塞逻辑。常见错误是把 rate.NewLimiter 当成“每秒放行 N 个请求”的开关其实它默认允许突发burst 1且 Allow() 不阻塞Wait() 才会等令牌。用错就等于没限流。rate.NewLimiter(rate.Every(100*time.Millisecond), 3) 表示平均 100ms 生成 1 个令牌最多攒 3 个burst3高并发下优先用 limiter.Wait(ctx)避免 Allow() 返回 true 后实际被后端压垮HTTP handler 中不要每个请求 new 一个 Limiter必须复用实例否则 burst 完全失效HTTP middleware 里怎么嵌入限流逻辑限流必须在路由分发前做否则中间件顺序错乱会导致部分 handler 被跳过。别在 handler 内部调 limiter.Wait()那是给单个业务逻辑用的不是 API 网关级控制。典型错误是把限流写在 http.HandleFunc 闭包里导致每个路径都独立限流——而你真正想控的是总 QPS 或按 IP 分组。立即学习“go语言免费学习笔记深入”用 http.Handler 包装原始 mux统一拦截http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { if err : limiter.Wait(r.Context()); err ! nil { http.Error(w, too many requests, http.StatusTooManyRequests); return } next.ServeHTTP(w, r) })需要按 IP 限流从 r.RemoteAddr 提取客户端 IP注意 X-Forwarded-For 可伪造生产需结合真实 IP 提取逻辑别在 middleware 里用 time.Sleep 模拟等待——这会占 goroutinelimiter.Wait() 是非阻塞调度更省资源rate.Limiter 的 burst 参数为什么不能设太小burst 是令牌桶的“水池大小”设成 1 就退化成严格匀速限流但真实流量天然有毛刺。用户连续点两次刷新、前端重试、CDN 预热都会触发瞬时高峰burst1 会让合法请求直接 429。 Vozo Vozo是一款强大的AI视频编辑工具可以帮助用户轻松重写、配音和编辑视频。