rate.Limiter不能用于分布式限流，因其仅在单机内存维护令牌桶状态，多实例间无共享与同步机制，导致总流量失控；必须依赖Redis+Lua实现原子性全局限流。
单机限流用 golang.org/x/time/rate 就够了；想防住真实流量洪峰，必须上分布式方案——rate.Limiter 在多实例下完全无效。
为什么 rate.NewLimiter 不能直接用于生产 API 防护
它只在当前进程内存里维护桶状态，每个服务实例都有一套独立的令牌计数。压测时你看到各节点 Allow() 返回 true，但总请求量早超阈值；用户从不同节点反复访问，限流形同虚设；突发流量打爆某台机器，其他实例却空转——根本原因是没共享状态。
常见错误现象：
- 下游 DB 或缓存连接池被打满，监控显示 QPS 远超配置值
- 同一 IP 在 A 节点被放过，在 B 节点又被放过，实际触发了双倍请求
- 用
sync.Map存*rate.Limiter实例，误以为“共享”，实则仍是单机视角
单机场景下怎么安全用 rate.Limiter
适合内部服务、CLI 工具、或明确知道只会部署单实例的边缘网关。关键点不是“能不能用”，而是“怎么避免踩坑”：
立即学习“go语言免费学习笔记（深入）”；
-
rate.NewLimiter(rate.Limit(10), 10)中第一个参数是每秒令牌生成速率（r），第二个是桶容量（b）；b决定突发容忍度，别设成 1 - 别用
Wait()阻塞等待令牌——HTTP 请求不该卡住 goroutine；改用Allow()或Reserve()+Delay()判断后主动返回429 - 如果用在 HTTP 中间件，确保
limiter实例是全局复用的，不是每次请求 new 一个 - 注意时钟精度：
Allow()基于time.Now()，若宿主机时间跳变（如 NTP 校正），可能瞬间耗尽令牌
分布式限流必须用 Redis + Lua
单靠 Go 代码无法解决原子性问题。Redis 的 ZSET + Lua 脚本能精确实现滑动窗口，比固定窗口更抗突增：
- 用
ZADD key now timestamp记录每次请求时间戳，score是秒级 Unix 时间 - Lua 脚本内先
ZREMRANGEBYSCORE key 0 (now - window)清旧数据，再ZCARD统计当前窗口请求数 - 所有操作在 Redis 单线程内原子执行，不存在竞态
- 示例键名建议带业务标识，比如
rl:api:/user/profile:192.168.1.100，避免不同接口/用户互相干扰
别用 INCR + EXPIRE 模拟——EXPIRE 不是原子的，窗口切换时可能漏计或重复计。
容易被忽略的细节：标识粒度与降级策略
限流效果好坏，一半取决于“按什么维度限”。IP？User ID？API Path？Token？这些选择直接影响公平性和防护强度：
- 仅按 IP 限：NAT 环境下会误伤，移动端 IP 经常变动
- 仅按 User ID 限：未登录请求无法识别，得 fallback 到 IP 或设备指纹
- 路径 + 用户组合：最精准，但 Redis 键数量爆炸，需评估 key 数量和内存占用
真正上线时，还得配降级开关：当 Redis 不可用，是直接放行（风险高）还是拒绝全部（体验差）？建议用本地 rate.Limiter 做二级兜底，同时上报告警——这比硬编码 fallback 更可控。
