Async库mapLimit/queue与async/await批量请求差异及限流脚本有效性问询

1. 你的脚本没有达成充分利用每秒20次请求的目标 #

存在两个核心问题导致性能浪费：

• 强制固定等待1秒的逻辑会产生无效空闲：你在每批次请求发送前先等待了整整1秒，就算上一批请求在几百毫秒内就全部完成，也必须等够1秒才会发下一批，白白浪费了大量可用请求额度。
• 必须等待整批请求全部完成才处理下一批：你通过await Promise.allSettled(batch)等待当前批次20个请求全部返回后才会进入下一轮循环，只要有一个慢请求卡壳，整批后续的请求都会被延迟，实际平均QPS远低于20。

举个例子，如果单接口平均耗时200ms，你的脚本实际每轮需要1秒等待+200ms请求处理，1.2秒才发20个请求，平均QPS只有16左右，完全没有打满限额。

2. Async库的mapLimit/queue和你的实现逻辑完全不一致 #

两者的核心差异如下：

• 你的实现是「固定批次间隔并发」：逻辑是按固定大小切分任务批次，批次之间强制等待固定时长，必须整批处理完成才会推进下一批，调度逻辑非常死板，很容易产生空闲时间。
• async.mapLimit是「固定并发数无批次调度」：不会对任务做批次切分，也没有强制等待逻辑，全程维持最多N个请求同时运行，只要有任意一个请求完成，就立刻从待处理列表里取新的请求补上，全程没有无意义的等待，能始终把并发数打满到设定阈值。
• async.queue是「动态任务队列并发」：在mapLimit的基础上还支持动态添加任务、调整并发数、设置任务优先级等能力，调度逻辑更灵活，同样是有空闲并发槽位就立刻执行新任务，不需要等待整批完成。

3. 符合需求的实现思路 #

如果要满足每秒最多20次请求的限制，同时打满限额，需要结合并发数控制和速率限流两个逻辑：可以用令牌桶/滑动窗口算法控制1秒内的请求总数不超过20，同时维持最多20个并发请求，只要有可用令牌和空闲并发槽位就发请求，不要做固定批次和固定等待的逻辑。

内容的提问来源于stack exchange，提问作者Álvaro