本文详解如何正确实现带并发限制的异步请求队列，指出原始代码因同步阻塞+异步回调时机错位导致的无限循环死锁问题，并提供可落地的递归+计数器方案。
在前端开发中，对大量 API 端点进行受控并发请求（如“最多同时发起 3 个请求，任一完成即补发下一个”）是常见需求。但若误用同步循环 + 异步 Promise 回调，极易陷入不可退出的同步死锁——这正是原始代码崩溃的根本原因。
? 问题根源：同步与异步执行模型的冲突
原始代码使用 while (endpoints.length > 0) 驱动请求，但在循环体内：
- limit-- 立即执行，首轮后 limit 归零；
- fetchMock(...).finally(() => limit++) 中的 limit++ 是异步回调，需等待当前调用栈清空后才入微任务队列；
- 而 while 循环永不退出（limit > 0 始终为 false），导致 JavaScript 主线程被完全占用，Promise 回调永无执行机会 → 死锁。
⚠️ 关键认知：Promise.then/catch/finally 的回调不会打断当前同步代码；它们只能在当前同步任务结束后、事件循环下一轮中执行。
✅ 正确解法：基于计数器的递归驱动队列
我们放弃阻塞式循环，改用主动触发 + 完成回调驱动后续请求的模式：
let activeCount = 0; // 当前活跃请求数
let offset = 0; // 下一个待请求索引
const requestQueue = (endpoints, callback, limit = 3) => {
// 终止条件：所有端点已入队或正在处理中
if (offset >= endpoints.length && activeCount === 0) return;
// 初始批量启动（最多 limit 个）
if (activeCount < limit && offset < endpoints.length) {
const endpoint = endpoints[offset++];
activeCount++;
fetchMock(endpoint)
.then(data => callback(null, data)) // 推荐区分成功/失败
.catch(err => callback(err, null))
.finally(() => {
activeCount--; // 请求结束，释放配额
// 立即尝试补充新请求（只要还有未发端点）
if (offset < endpoints.length) {
requestQueue(endpoints, callback, limit);
}
});
}
};
// 模拟请求（带随机延迟，便于观察并发效果）
function fetchMock(endpoint) {
const delay = Math.floor(Math.random() * 3000) + 1000; // 1–4s
return new Promise(resolve =>
setTimeout(() => resolve(`result_from_${endpoint}`), delay)
);
}
// 使用示例
requestQueue([1, 2, 3, 4, 5], (err, data) => {
if (err) console.error('Request failed:', err);
else console.log('Success:', data);
});✅ 方案优势与注意事项
- 无死锁风险：完全异步驱动，不依赖同步循环；
- 精准限流：activeCount 实时统计并发数，确保任意时刻 ≤ limit；
- 高响应性：任一请求完成即刻发起下一个，最大化吞吐；
- 错误隔离：单个请求失败不影响队列整体执行；
- 可扩展性强：易于添加重试、超时、取消等高级能力。
? 进阶提示：生产环境推荐使用成熟库如 p-limit 或 axios-rate-limit，它们已内置错误处理、取消信号（AbortController）和更健壮的边界条件覆盖。
通过理解事件循环机制与 Promise 执行时机，你就能避开这类“看似合理却必崩”的陷阱，写出真正可靠、可维护的异步控制逻辑。
