整分钟都没超额，为何连续六十秒仍超限：限流窗口怎样验收

“每个整分钟都没有超过三次”与“任意连续六十秒都不超过三次”是不同约束。请求挤在分钟边界两侧时，前一种算法可以短时间放出两批。本文给固定窗口与滚动窗口同一组毫秒时间戳，逐项比较准入集合。

先写清楚窗口包含哪一端

固定窗口使用从起点开始的整分钟编号，零到六十秒属于第一桶，六十到一百二十秒属于第二桶。滚动窗口在当前时刻t查看大于t减六十秒、且不晚于t的已放行请求，也就是左开右闭。被拒请求不进入本例计数；如果你的产品会统计尝试数，需要另建契约，不能直接套用附件答案。

输入前六项分成两组：三项在五十九点九秒，三项在六十点一秒，同一时刻按原始行序排序。固定窗口两组分别占满各自桶，放行序号零到五；滚动窗口在第二组到达时仍记得第一组，只放行零、一、二。短短零点二秒里，固定窗口已经允许六次，但它没有违反自己的整分钟规则。

用恰好六十秒的间隔找边界错误

第七项在一百一十九点九秒。它与第一组恰好相隔六十秒，第一组从滚动窗口移出，因此第七项可以放行；固定窗口的第二桶已经满，反而拒绝第七项。最终固定集合为零到五，滚动集合为零、一、二、六。这个反转能防止把滚动窗口简单理解成“永远比固定窗口更严格”。

若实现使用大于等于而不是大于筛选旧事件，第一组会多保留一个边界点，第七项就被误拒。毫秒取整、跨进程排序和同毫秒事件的稳定顺序也应写入样本。一次人工看墙上时钟，很难抓住这些差异；固定整数时间戳则可以在库升级后重复验证。

只对自己声明的算法作结论

附件没有访问提供方，更没有证明某个真实平台采用固定或滚动窗口。真实配额可能同时受多个周期、请求权重和token量影响。接入前应核对官方规则，把该规则转换成自己的输入向量；出现429时也不要仅凭整分钟报表认为上游统计错误。

运行时计算经过时间可使用单调时钟，持久日志仍需能与UTC时刻关联。离线参考器不检验分布式时钟、共享计数原子性和节点重启后的状态。它交付的独立价值是逐行允许列表与边界解释，适合用来审查一个已经选定的窗口算法，而不是用“分钟内总量看着正常”代替真正的准入验收。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C006。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

补充文件：c006-arrival.csv。合成表供独立复算，配置片段是否实跑以正文说明为准。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文讲RPM/TPM与并发规划；本文只比较分钟边界两侧的离散准入集合，不估算生产并发、不解释基础单位。