rate.Limiter在生产环境常“形同虚设”是因为它仅单机生效，多实例部署时总流量为单机阈值×实例数，且不感知用户身份、无法直接实现用户级限流，需配合sync.Map或Redis+Lua才能支撑分布式与业务维度限流。
rate.Limiter 是 Go 里最常用、也最容易误用的限流组件。它默认只做单机令牌桶，不跨进程、不跨实例、不感知用户身份——直接拿来就用，90% 的线上限流失效都源于此。
为什么 rate.Limiter 在生产环境常“形同虚设”？
它只在当前 goroutine 所在的进程内生效。当你用 Nginx 做负载均衡，后端部署 4 台 Go 实例时，每台机器各自维护一个桶，总流量上限其实是单机阈值 × 4。
- 比如你设了
rate.Limit(10)（每秒 10 请求），实际可能每秒放行 40 个请求 - 对同一 IP 或用户 ID 的请求完全无感知，无法实现“每个用户每分钟最多 60 次”这类业务规则
- 桶容量（burst）设得过大时，会放大突发流量，反而加剧下游压力
按用户 ID 限流必须自己维护状态
Go 标准库不提供开箱即用的用户级限流。你需要明确选择状态存储方式和一致性模型：
- 单机精确控制 → 用
sync.Map+ 滑动窗口（如SlideWindowLimiter），但需自行清理过期时间戳，否则内存持续增长 - 多实例共享 → 必须依赖外部存储，推荐 Redis + Lua 脚本，用
INCRBY和EXPIRE组合保证原子性 - 避免用 HTTP session 或本地文件存限流状态：不可靠、不一致、难扩容
固定窗口 vs 滑动窗口：别被“简单”骗了
FixedWindowLimiter 实现短、测试快，但存在临界突刺问题：两个相邻窗口各放行满额请求，导致瞬时流量翻倍。例如 1 秒限 5 次，第 0.9 秒进 5 个，第 1.1 秒又进 5 个，实际 0.2 秒内就压了 10 个请求。
- 滑动窗口精度高，但需要维护时间切片或排序队列，CPU 和内存开销明显上升
- go-zero 选固定窗口，是因为它用 Redis 做计数器，靠
EXPIRE自动清理，牺牲一点精度换确定性 - 若业务对突刺敏感（如支付、发短信），必须上滑动窗口或令牌桶 + 用户维度 key
分布式限流绕不开 Redis 和 Lua
所有靠谱的分布式限流方案，最终都落到 Redis 上执行原子操作。关键不是“要不要用 Redis”，而是怎么用：
立即学习“go语言免费学习笔记（深入）”；
- 不要在 Go 里先
GET再INCR：竞态条件会导致超限 - 必须用 Lua 脚本封装逻辑，例如 go-zero 的
periodScript，把计数、过期、重置全包在一个原子事务里 - Key 设计要带业务标识，如
"rl:uid:12345:1m"，避免不同用户或资源互相干扰 - Redis 连接池大小要调优；限流失败不能阻塞主流程，建议 fallback 到本地
rate.Limiter保底
