本文详解为何原始代码会陷入死循环，并提供一个真正可用的并发限制请求队列实现，支持“空闲即补发”策略（如3路并发、任一完成立即发起下个请求）。
在前端开发中，对大量接口进行并发请求时，若不加控制，极易触发浏览器连接数限制、服务端限流或内存溢出等问题。一个常见需求是：最多同时发起 N 个请求，每当有请求完成，立即用下一个待请求的 endpoint 补位，保持通道尽可能饱和——这被称为“动态限流队列”或“滑动并发窗口”。
但直接使用 while + 同步 splice + 异步 fetch 的组合（如原代码）会导致严重问题：
❌ 原始代码为何崩溃？
while (endpoints.length > 0) {
if (limit > 0) { // ← 第一次后 limit 变为 0，此后永远跳过此分支
const slice = endpoints.splice(0, limit); // ← endpoints 被修改，但仅第一次执行
for (const endpoint of slice) {
limit--; // ← limit 快速归零
fetchMock(endpoint).finally(() => limit++); // ← Promise 回调异步执行，但同步 while 永不停止！
}
}
}关键错误在于：
- limit-- 在同步循环中迅速归零，导致 if (limit > 0) 后续恒为 false；
- Promise.then().finally() 是微任务，必须等当前同步栈清空后才执行；
- 而 while 循环永不退出 → 同步栈永不清空 → 所有 .finally() 永不运行 → limit++ 永不发生 → 死锁。
✅ 核心原则：不能在同步循环中依赖异步回调来驱动流程控制。
✅ 正确解法：基于 Promise 链与递归调度的动态队列
我们改用「主动调度」模型：维护一个全局索引 offset，每次成功/失败后检查是否还有待请求项，有则立即发起新请求：
let offset = 0;
const requestQueue = (endpoints, callback, limit = 3) => {
// 初始启动：并发发出前 limit 个请求
if (offset === 0) {
for (let i = 0; i < Math.min(limit, endpoints.length); i++) {
makeRequest(endpoints, callback);
}
}
};
function makeRequest(endpoints, callback) {
if (offset >= endpoints.length) return;
const current = endpoints[offset++];
console.log(`[REQ] ${current} (concurrency: ${offset - 1})`);
fetchMock(current)
.then(data => callback(null, data)) // 推荐区分 success/error
.catch(err => callback(err, null))
.finally(() => {
// 请求结束，若有剩余 endpoint，立即发起下一个
if (offset < endpoints.length) {
makeRequest(endpoints, callback);
}
});
}
// 模拟带随机延迟的请求
function fetchMock(endpoint) {
const delay = Math.floor(Math.random() * 3000) + 1000;
return new Promise(resolve =>
setTimeout(() => resolve(`result-${endpoint}`), delay)
);
}
// 使用示例：5 个 endpoint，最多 3 个并发
requestQueue([1, 2, 3, 4, 5], (err, data) => {
if (err) console.error('[ERR]', err);
else console.log('[OK]', data);
});✅ 进阶优化建议
- 避免全局变量：将 offset 封装为闭包或类实例属性，支持多队列并行；
- 错误隔离：单个请求失败不应阻塞整个队列，.catch() 后仍应 makeRequest()；
- 取消能力：可引入 AbortController，配合 signal 参数增强健壮性；
- 返回 Promise.allSettled 结果：如需汇总全部响应，可在所有请求完成后 resolve 数组。
? 总结
- ✅ 正确思路：用「完成即调度」替代「预分配+同步等待」；
- ✅ 关键机制：offset 索引 + 递归 makeRequest + finally 触发后续；
- ❌ 绝对避免：在同步循环中修改控制变量并依赖异步回调恢复它；
- ? 提升可维护性：考虑使用成熟库如 p-limit 或 Promise.map(..., { concurrency: 3 })（via p-map）。
该模式不仅适用于 mock 请求，也完全兼容真实 fetch、axios 等场景，是构建高可靠批量数据加载器的基础范式。
