rate.Limiter适合单机、轻量、低延迟接口的速率控制，如内部管理后台、配置查询类接口；基于令牌桶算法，内存占用小、无外部依赖，Allow()和WaitN()调用开销在纳秒级。
rate.Limiter 适合什么场景？
单机、轻量、低延迟接口的速率控制，比如内部管理后台、配置查询类接口。它基于令牌桶，内存占用小、无外部依赖，Allow() 和 WaitN() 调用开销在纳秒级。
但别把它用在网关或核心 API 层：所有实例各自维护状态，集群下实际 QPS 是单机阈值 × 实例数；规则无法热更新；没熔断联动；错误率、响应时间等维度完全不可控。
-
rate.NewLimiter(10, 1)中第二个参数是“突发容量”，不是缓冲队列——超限请求立刻返回 false，不会排队 - 若用
WaitN()阻塞等待，必须设 context timeout，否则协程可能永久挂起 - 不要在 HTTP handler 里每次 new 一个
rate.Limiter，它不是线程安全的，应全局复用
Redis + Lua 滑动窗口为什么更靠谱？
跨实例一致性是硬需求时，滑动窗口是目前最平衡的选择：精度高（毫秒级窗口）、边界效应小、支持动态限流阈值。关键不在于 ZSet 多酷，而在于原子性——ZRemRangeByScore + ZCard + ZAdd 必须打包进 Lua 脚本执行，否则并发下计数会错。
常见翻车点是漏掉 Expire：ZSet 本身不自动过期，靠客户端手动设 TTL，如果某次写入失败，key 可能永久残留，下次统计就偏高。
立即学习“go语言免费学习笔记（深入）”；
- 窗口时间建议 ≥ 1 秒，太短（如 100ms）会导致 Redis 压力陡增，且对突发流量抑制效果变差
- score 用
UnixMilli()，不是Unix()，否则秒级精度下无法区分同一秒内多个请求 - 不要在 Lua 脚本里做复杂逻辑（比如判断用户等级再决定阈值），脚本越重，Redis 单线程阻塞越久
Sentinel Go 的 blockHandler 和 fallback 别混用
blockHandler 是限流被拒时的兜底，fallback 是熔断触发后的降级，二者触发条件、时机、上下文完全不同。混用会导致该返回缓存时返回了错误码，或者该快速失败时反而去查数据库。
典型错误是把所有降级逻辑都塞进 fallback 函数——结果限流打进来时没人处理，用户看到 500；或者在 blockHandler 里调 sentinel.Entry("xxx")，引发嵌套资源注册和死循环。
-
blockHandler应返回与正常接口结构一致的 JSON，字段填默认值（如{"data": []}），前端无需改逻辑 -
fallback里禁止发起新 RPC 或 DB 查询，只读内存变量或预加载的本地缓存 - 资源名必须带业务前缀，比如
"order-service:create"，不能写成"api"—— 否则所有接口共用一套规则，根本没法精细化治理
gobreaker 熔断器的三个参数怎么设才不误伤？
MaxRequests、Interval、Timeout 这仨不是拍脑袋定的。设大了，故障扩散快；设小了，抖动就熔断，服务比人还敏感。
真实线上经验：对下游 HTTP 调用，优先用 ErrorRatioStrategy，错误率阈值 0.3～0.5，但必须叠加最小错误数（比如 ≥5），避免偶发超时就开闸；对内部 gRPC，用 SlowRatioStrategy，P95 RT + 20% 作阈值，半开探测请求数设为 3～5，别贪多。
-
Interval不是“多久检查一次”，而是“滚动窗口长度”——设成 60 秒，就统计最近 60 秒内的错误率 -
Timeout是熔断后保持 Open 态的最短时间，不是恢复时间；恢复由半开态自动触发，跟这个值无关 - 别给每个调用都配独立
CircuitBreaker实例，复用同一个实例并传不同name参数，减少 goroutine 和内存开销
