本文详解为何原始代码会陷入死循环，并提供一个真正可用的并发限制请求队列实现，支持“空闲即补发”策略（如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 等场景，是构建高可靠批量数据加载器的基础范式。