生产环境应使用 golang.org/x/time/rate：它由 go 官方维护、百万 qps 验证，基于原子操作+时间轮，高性能且线程安全；limit 单位为每秒令牌数，需换算（如每200ms限10次→limit(50)），burst 是桶容量而非队列长度，应≥p95并发峰值；allow()适合强实时场景但易丢请求，wait(ctx)更适合用户接口且必须带超时；单机限流在集群下无效，需redis+lua等分布式方案；限流、熔断、降级须职责分离，blockhandler返回默认json，fallback禁用远程调用，熔断须按接口粒度隔离。
生产环境别手写限流器，直接用 golang.org/x/time/rate —— 它是 Go 官方维护、百万级 QPS 验证过的实现，底层用原子操作+时间轮，比任何锁版都快且线程安全。
rate.Limiter 的 Limit 和 Burst 参数怎么设才不翻车
常见错误是把 rate.Limit 当成“每 N 毫秒多少次”直接填数字，忽略单位换算。它只认“每秒令牌数”，所以：
- 想限“每 200ms 最多 10 次”，得换算成每秒 50 次 →
rate.Limit(50)，再配Burst=10 -
Burst不是缓冲队列长度，而是桶最大容量：它决定你能扛住多少瞬时并发，不是排队等待人数 - 设
rate.NewLimiter(10, 1)意味着空闲时最多放行 1 个请求，之后必须等 100ms 才能再进——实际体验就是“卡顿式拒绝”，别这么干 - 高并发 HTTP 接口建议
Burst ≥ 期望的 P95 并发峰值，比如压测看到 30 QPS 下峰值并发是 8，Burst 至少设 10
Allow() 和 Wait() 到底该用哪个
Allow() 立即返回 bool，适合强实时场景（如支付回调验签），但会粗暴丢弃等待意图；Wait() 会阻塞直到拿到令牌或超时，更适合用户可见接口（如商品详情页）。关键区别在于是否接受小幅排队：
- 用
Allow()必须搭配足够大的Burst，否则小流量抖动就触发大量429 - 用
Wait(ctx)一定要传带超时的context，否则 goroutine 可能永久挂起（比如下游卡死，令牌永远不来） - 中间件里只写
if !limiter.Allow() { http.Error(...429...) }是典型反模式：突发流量下监控毛刺式报错，而系统负载其实很低 - 真实 HTTP handler 示例：
ctx, cancel := context.WithTimeout(r.Context(), 200*time.Millisecond)<br>err := limiter.Wait(ctx)<br>cancel()<br>if err != nil {<br> http.Error(w, "Too many requests", http.StatusTooManyRequests)<br> return<br>}
单机限流在集群下为什么等于没限
rate.Limiter 是纯内存结构，每个实例各自维护状态。如果你有 10 个服务实例，每个配了 rate.NewLimiter(100, 20)，那集群实际允许的 QPS 就是 1000，远超预期阈值。这不是 bug，是设计使然：
- 它适合单机轻量场景：内部管理后台、配置查询、低频定时任务
- 网关层或核心 API 层必须用分布式方案，比如
Redis + Lua实现滑动窗口——ZSet 的score用time.UnixMilli()，所有操作打包进一个 Lua 脚本保证原子性 - 漏掉
EXPIRE是高频翻车点：ZSet 不自动过期，key 残留会导致后续统计虚高 - 别指望靠
sync.Map+ IP 维度限流解决集群问题：它只是缓解单机维度倾斜，跨实例仍无协同
降级和熔断不能混在同一个函数里处理
限流被拒走 blockHandler，熔断触发走 fallback，二者触发条件、上下文、数据来源完全不同。混用会导致该返回缓存时返回了错误码，或者该快速失败时反而去查数据库：
-
blockHandler应返回与正常接口结构一致的 JSON，字段填默认值（如{"data": []}），前端无需改逻辑 -
fallback只能读内存变量或预热好的本地缓存，禁止发起新 RPC、DB 查询或 HTTP 调用——否则主服务挂了，降级路径也跟着雪崩 - 熔断器必须按接口粒度隔离：
gobreaker.CircuitBreaker或sentinel.Entry("order-service:pay")，不能全服务共用一个 - 错误类型要分清：只对
context.DeadlineExceeded、net.ErrClosed、HTTP502/503/504降级；400、401、sql.ErrNoRows这类业务错误绝不 fallback
真正难的不是选算法，而是搞清每个组件的边界：rate.Limiter 不负责熔断，Sentinel 不替代连接池，降级数据必须提前加载好。线上出问题，八成是因为把不同层次的防护逻辑揉进了同一个 if 分支里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
