固定窗口限流在laravel中会因redis incr与expire非原子性及窗口切换突刺导致服务崩溃；应改用滑动窗口，通过redis hash分10个100ms槽位或sorted set按时间戳精确统计，避免临界流量叠加。
在Laravel应用中实现接口限流时，若直接用Redis固定窗口计数器，会在每秒切换时刻遭遇请求突刺——前一秒末尾+后一秒开头的流量叠加可能瞬间压垮服务。这个问题必须在代码层解决，不能依赖运维补丁。
为什么固定窗口在Laravel里会崩
Redis INCR + EXPIRE 组合看似简单：每次请求执行 INCR key → 检查返回值是否 ≤ 限制数 → 若超限则拒绝 → 同时用 EXPIRE key 1 设置1秒过期。但问题出在EXPIRE不是原子操作：当大量请求在毫秒级内涌入，INCR 可能成功多次，而 EXPIRE 却因key已存在被忽略，导致该key长期存活，后续所有请求都被错误拦截。
更致命的是窗口切换瞬间：0.999秒时key还有9次余量，0.001秒后新窗口开启，旧key自动过期，新key从0开始计数——两批请求在1ms内叠加，实际QPS翻倍。
用滑动窗口替代固定窗口
把1秒拆成10个100ms小格，每个格子独立计数。窗口始终覆盖最近10个格子（即最近1秒），实时求和判断。这样既保留窗口概念，又消除临界突刺。
方法一：Redis Hash结构存储时间槽
第一步：用当前时间戳向下取整到100ms粒度，生成slot_key，例如1722955386100（毫秒级时间戳截断最后一位）
第二步：执行 HINCRBY rate_limit:api:uid_123 $slot_key 1
第三步：用 HRANGE rate_limit:api:uid_123 0 -1 获取全部槽位值，或更高效地用 HEXISTS + HGET 查最近10个slot（需计算slot范围）
第四步：对这10个slot的数值求和，若 ≥ 限制数（如100），则拒绝请求
第五步：为每个slot设置TTL = 1050ms（比1秒多50ms，确保窗口滑动时旧slot自然过期）
【slot_key必须用毫秒时间戳截断而非秒级，否则无法区分100ms粒度】
Laravel中间件落地代码
创建 app/Http/Middleware/SlidingWindowRateLimit.php：
构造函数里注入 Redis 实例，并预设窗口大小（1000ms）、槽位数（10）、单槽限额（10）——三者关系：总限额 = 单槽限额 × 槽位数
handle 方法中先调用 $this->getCurrentSlot() 获取当前100ms槽位键名，再执行 $redis->hIncrBy($hashKey, $slotKey, 1)
接着用 $redis->hGetAll($hashKey) 拉取全部槽数据，遍历过滤出 timestamp ≥ (now - 1000) 的10个槽，累加计数
若累加值 > 总限额，则返回 response()->json(['error' => 'Too Many Requests'], 429) 并终止请求
最后调用 $redis->expire($hashKey, 1050) 确保Hash整体过期时间兜底，防止槽位无限堆积
关键细节处理
方法二：用Redis Sorted Set替代Hash（更精确控制过期）
每次请求执行 ZADD rate_limit:api:uid_123 $timestamp $request_id，其中 timestamp 是毫秒时间戳
然后用 ZCOUNT rate_limit:api:uid_123 ($lower_bound $upper_bound 统计最近1秒内请求数，lower_bound = now - 1000，upper_bound = now
再用 ZREMRANGEBYSCORE rate_limit:api:uid_123 0 $lower_bound 清理过期请求记录
【ZCOUNT的区间是开区间，$lower_bound 必须加括号写成 ($lower_bound，否则会包含边界点造成统计偏差】
这个方案无需预设槽位数，天然支持任意精度滑动，但内存占用略高——每个请求存一个score+member，适合QPS不超5000的业务。
