rate.Limiter够用但仅限单机场景，分布式下因状态不共享而失效；Redis+Lua实现原子性令牌桶最可靠，Consul/Etcd因延迟高、无原生过期不推荐用于高频限流。
限流选 golang.org/x/time/rate 还是自己写令牌桶？
直接说结论：rate.Limiter 够用，但默认配置在分布式场景下会失效。它只在单机内存里维护桶状态，节点一扩缩容、请求一跨机器，限流就形同虚设。
常见错误现象：本地压测一切正常，上线后 QPS 突然翻倍，监控显示限流几乎没生效——八成是因为你把 rate.Limiter 当成全局开关用了。
- 适用场景：单服务进程内限流（如防止单个 HTTP handler 被打爆）
- 不适用场景：用户级/接口级全链路限流、多实例共享配额（比如“每个 uid 每分钟最多调用 100 次”）
-
rate.Every(100 * time.Millisecond)和rate.Limit(10)效果等价，但前者更易读；注意burst参数不是并发数，而是允许突发的请求数，设太大等于没限 - 性能影响极小，无锁实现，但别把它塞进 hot path 的循环里反复 new —— 复用一个实例即可
Redis + Lua 实现分布式令牌桶为什么比单纯 INCR 更可靠？
因为原子性。单纯用 INCR + EXPIRE 两步走，在网络分区或进程崩溃时，可能漏掉过期设置，导致 key 永久存在、配额锁死。
真实使用中，90% 的 Redis 限流失败都源于没处理好时间窗口重置和初始 key 写入竞争。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须用 Lua 脚本封装“读当前值 → 判断是否可消费 → 更新值 → 设置过期”整套逻辑，否则无法保证一致性
- key 命名要带时间窗口，比如
limit:uid:12345:202405（按月）或limit:api:/order:2024052014（按小时），避免不同窗口互相覆盖 - 注意 Redis 的
PTTL返回 -2（key 不存在）和 -1（无过期），Lua 里得显式判断，否则脚本可能误判为“有配额” - 如果用
redis-go客户端，别依赖Do()手动拼 Lua，优先用Eval()或封装好的限流库（如go-redsync配合 Lua）
sentinel-golang 和自研基于 Redis 的限流器差在哪？
差在熔断联动和规则热更新能力。sentinel-golang 不是纯限流器，它是把限流、降级、系统保护打包在一起的控制面，适合已接入 Sentinel 生态的团队。
但如果你只想要轻量、确定性强的限流，它反而增加心智负担：配置项多、metric 上报强耦合 Prometheus、动态规则依赖 sentinel-dashboard。
- 自研方案优势：逻辑透明、调试方便、可精准控制失败返回码（比如对 VIP 用户返回 429，普通用户直接 503）
-
sentinel-golang优势：自带滑动窗口统计、自动 fallback、支持集群流控模式（需额外部署 token server） - 兼容性注意：
sentinel-golangv1.x 默认用内存滑动窗口，v2.x 才支持 Redis 存储指标，升级前务必看 CHANGELOG - 性能上两者差距不大，但
sentinel-golang的 metric 收集默认开销略高，压测时建议关掉metrics.Reporter
为什么用 consul 或 etcd 做限流中心不如 Redis？
不是不能用，是没必要。限流的核心诉求是低延迟、高吞吐、强原子写，而 Consul/Etcd 的设计目标是强一致配置同步，写入路径长、QPS 上限低、Watch 机制不适合高频计数。
线上见过最典型的坑：用 Etcd 的 CompareAndSwap 实现令牌桶，结果 etcd leader 切换期间大量请求超时，限流器直接退化成“随机放行”。
- Redis 的
EVALSHA可以把 Lua 脚本预加载，单次调用延迟稳定在 0.2–0.5ms；Etcd 的 CAS 至少 5–10ms，且不支持批量操作 - Consul 的 KV 接口没有原生过期支持，得靠 TTL check goroutine 清理，容易积压 stale key
- 如果硬要用，只适合极低频、高一致性要求的场景（比如“每天最多发 1 条短信”的全局配额），且必须加 client 端缓存 + 降级策略
- 真正需要多数据中心协同限流时，别自己搞，用
redis-cluster+redis-cell（T-Redis 扩展）或商业方案（如阿里云 AHAS）
分布式限流最难的从来不是算法本身，而是怎么让“窗口对齐”“时钟漂移”“网络分区恢复后状态自愈”这些细节不出错。多数人卡在第一步：没想清楚到底要限什么——是单机资源、接口 QPS、用户行为，还是下游依赖容量。定不准这个，再好的库也救不了。
