滑动窗口限流不能用RateLimiter实现，因其是令牌桶算法，只控制速率、不记录时间戳、无法统计“最近N秒内请求数”，必须用Redis ZSet配合Lua脚本原子执行清理、统计、写入三步操作。
滑动窗口限流不是靠 RateLimiter 实现的——Guava 的 RateLimiter 是令牌桶，固定速率发放许可，不支持“最近 N 秒内最多 M 次”这类统计型窗口逻辑。真要实现滑动窗口，得换思路。
为什么 RateLimiter 不能直接做滑动窗口
它底层维护的是一个平滑的令牌生成器，tryAcquire() 判断的是“此刻有没有令牌”，而不是“过去 60 秒里你总共发了多少请求”。哪怕你设成 RateLimiter.create(100.0)，它也只保证长期平均 100 QPS，无法防止某秒内突发 200 次请求打穿服务。
- 令牌桶适合控制**速率**（如 API 调用节奏），不适合做**计数型限流**（如“每分钟最多 100 次”）
-
RateLimiter是单机内存态，无时间戳记录，没法回溯历史请求 - 它的
acquire()会阻塞，而滑动窗口通常要求非阻塞 + 立即拒绝
滑动窗口必须用 Redis ZSet + Lua 脚本
这是目前最稳妥、原子性最强的落地方式。核心是把每次请求的时间戳写进 ZSet，用 ZRANGEBYSCORE 和 ZREMRANGEBYSCORE 维护窗口边界。
- Redis key 建议按维度组合，比如
ratelimit:ip:192.168.1.1或ratelimit:uid:1001 - Lua 脚本必须同时完成三件事：清理过期项、统计当前窗口请求数、插入新时间戳——否则竞态条件会导致超限放行
- 窗口精度别设太细，例如用毫秒级时间戳当 score，容易撑爆内存；推荐用秒级或 100ms 级（
System.currentTimeMillis() / 100） - 注意
ZCard返回的是整个集合大小，不是窗口内数量，一定要用ZCount配合 score 范围
Spring AOP + 注解实现时的关键陷阱
很多项目用 @RateLimiter 注解封装滑动窗口，但实际运行中常失效，问题多出在以下几点：
- 没配
StringRedisTemplate.setKeySerializer()和setValueSerializer()，导致 Lua 脚本读到乱码或空值 - 注解里的
time单位是秒，但 Lua 脚本里误用毫秒计算窗口范围，结果窗口永远清不干净 - 没加
@EnableAspectJAutoProxy(exposeProxy = true)，AOP 在内部方法调用时失效 - 异常类型没统一，
RateLimitException被全局异常处理器吞掉却没返回 429，前端以为成功了
.NET 8+ 用 ResiliencePipeline 的正确姿势
如果你在 .NET 生态，别手写滑动窗口——直接用 Microsoft.Extensions.Http.Resilience，但它只对 HttpClient 生效，不是中间件。
- 限流策略必须通过
AddResilienceHandler()显式挂载，注册了RateLimiterStrategyOptions但没挂载，等于没写 - 默认是内存计数器，多实例部署时必须替换为
RedisRateLimiter，且需提前注入IDistributedCache -
QueueLimit = 0表示禁用排队，超限时直接返回 503；设为正数才启用排队，但要注意队列积压风险 - 它不支持按路由模板或 header 动态提取 key，如需 IP + path 组合限流，得自己写
IRateLimiter实现
滑动窗口真正的难点不在算法本身，而在时间精度取舍、Redis 数据生命周期管理、以及分布式环境下 key 的一致性设计。随便套个“滑动窗口”名字，但没处理好窗口切片和过期清理，就只是个带延迟的固定窗口。
