p-queue 窗口已经过期，新任务却还要等半秒

队列设置 intervalCap: 2, interval: 1000，第一项在窗口开头执行，第二项在约600毫秒时执行。窗口过期后再加入第三项，它却等到约1600毫秒才开始，而不是在加入时立即取得新窗口名额。

若实际使用 p-queue 9.3.2，检查队列中途变空、间隔定时器已经停止的分支。这个版本会额外比较最近任务的执行时刻，将窗口延长到“最后一项加 interval”。当一个窗口允许多项任务时，最后一项不一定在窗口开头，这个比较就可能造成额外等待。

先确认采用的限流模型

concurrency 限制同时运行的任务数，intervalCap 限制一个时间窗口内的启动数量。任务已经完成、pending 为零，也不表示速率窗口的使用记录应该全部清空。

strict 的滑动限制又是另一种策略。若业务要求任意一秒最多两次，窗口边界本来就不应与普通固定窗口完全一样。不能只为让一次任务更快，把 strict 关掉或把 interval 改小。

本问题的判断条件是普通固定窗口、intervalCap 大于1、上一窗口内的启动时刻分散，并且队列空闲后重新收到任务。其他任务仍在运行、carryoverIntervalCount 计入旧任务等情况，需要按原配置另算名额。

正式 9.3.3 已移除这条额外时间判断

9.3.3 的对应逻辑改为使用 intervalEnd 判断空闲后的窗口边界，不再通过 lastExecutionTime 延长它。升级到兼容的正式版本后，仍需保留并发、窗口长度、窗口配额和 carryover 配置，不能同时改变多个策略再归因于版本修复。

若只需要修正这个旧分支，不一定要跨到10。p-queue 10 改用了 EventTarget，并要求更新的运行时，旧的事件监听写法需迁移。先核对实际解析的依赖，避免顶层升级后运行包仍包含另一份9.3.2。

不要在队列空闲时重新创建实例，试图清空窗口历史。这会让跨实例的总请求数失去限制，也可能丢掉原有优先级、监听器和待处理工作。调用 clear 也不是重置速率预算的正确方式。

记录入队、启动和结束三个时刻

在受控任务上重现“窗口早段启动一项、晚段启动一项、空闲、跨边界再加入”的顺序，比较第三项的入队和实际开始时间。定时器调度有误差，应容许合理误差范围，不要要求每次输出固定的毫秒数。

还要验证正常满窗口、没有空闲的连续任务、strict 模式以及 carryover 的既有行为。最终目标是按照既定速率策略启动任务，不是单纯缩短等待；服务端若仍返回限流响应，应继续按其配额和重试约定处理。