本文旨在解决前端应用中处理大量网络请求时遇到的api超时、403错误等问题。通过分析常见的错误尝试，文章重点介绍了如何利用bluebird.map进行并发控制，以及如何手动实现分批处理和延迟执行请求，从而有效管理请求负载，避免api限流，确保应用稳定性和用户体验。
引言：处理大量网络请求的挑战
在现代Web应用开发中，我们经常需要向后端API发送大量网络请求，例如批量数据更新、文件上传等场景。然而，当请求数量达到一定规模（如数百甚至上千个）时，直接使用Promise.all等方式并行发送所有请求，往往会导致以下问题：
API 限流或超时：后端服务器可能无法承受瞬间涌入的大量请求，从而触发限流机制，返回429（Too Many Requests）或403（Forbidden）错误，甚至导致请求超时。浏览器资源耗尽：在客户端，同时维护大量待处理的网络连接会消耗大量内存和CPU资源，可能导致浏览器卡顿或崩溃。用户体验下降：请求失败或长时间无响应都会严重影响用户体验。
以下是一个典型的、可能导致问题的Promise.all实现示例：
const retry = async (requests: API.CarFailedRequest[]) => { setIsLoading(true); const res = await Promise.all( requests.map(async request => { try { await service.retryFailedRequest(request); return { status: true, request }; } catch (e) { return { status: false, request }; } }) ); setIsLoading(false); return res;};
这段代码的问题在于，requests.map内部的async request => {…}函数会立即执行，从而创建并启动所有的Promise。Promise.all随后等待所有这些已启动的Promise完成，但此时所有的网络请求已经同时发出，导致上述问题。
错误尝试分析
在尝试解决上述问题时，开发者可能会采取一些看似合理但实际上未能达到预期效果的策略。理解这些尝试为何失败，对于构建正确的解决方案至关重要。
尝试一：Bluebird.map 的误用
一种常见的尝试是引入像 Bluebird 这样的第三方库，它提供了更强大的并发控制能力。然而，如果使用不当，效果可能不佳。
// 错误的 Bluebird.map 使用方式const retry = async (requests: API.CarFailedRequest[]) => { setIsLoading(true); const promises = requests.map(async request => { try { await service.retryFailedRequest(request); return true; } catch (e) { return false; } }); await BlueBirdPromise.map( promises, // 注意：这里传入的是一个已启动的Promise数组 async promise => { try { await promise; } catch (err) { console.log(err); } }, { concurrency: 10 } ); setIsLoading(false);};
这段代码的问题在于，requests.map 仍然在 BlueBirdPromise.map 调用之前就创建并启动了所有的 Promise。promises 数组中存储的是已经开始执行的网络请求。BlueBirdPromise.map 的 concurrency 选项虽然限制了同时处理 Promise 结果的数量，但它无法阻止这些 Promise 在被传入 map 之前就全部启动。因此，网络请求仍然是瞬间全部发出的。
尝试二：手动分块但未延迟请求启动
另一种思路是手动将请求分成小块（chunks），并尝试在每个块之间添加延迟。
// 错误的 manual chunking 方式const processPromisesWithDelay = async (promises: any[], delay: number, split: number) => { const chunks = []; for (let i = 0; i any) => promise())); // 问题在这里：promise() 意味着立即执行 await new Promise((resolve) => setTimeout(resolve, delay * 1000)); }};const retry = async (requests: API.CarFailedRequest[]) => { setIsLoading(true); const promises = requests.map(async request => { await service.retryFailedRequest(request); // 再次：所有请求在这里就启动了 }); await processPromisesWithDelay(promises, 5, 5); // 传入的是已启动的Promise数组 setIsLoading(false);};
与 Bluebird.map 的误用类似，requests.map 在 processPromisesWithDelay 调用之前就启动了所有请求。即使 processPromisesWithDelay 试图分批处理并添加延迟，它操作的仍然是已经发出的网络请求。在浏览器网络面板中，你会看到所有请求几乎同时处于“pending”状态，只是它们的完成时间被分批等待了，而不是请求的启动时间被分批了。
解决方案一：使用 Bluebird.map 进行并发控制
解决上述问题的关键在于，并发控制应该作用于请求的启动时机，而不是 Promise 的解决时机。Bluebird.map 正是为此设计的，但需要正确使用它。
商汤商量
商汤科技研发的AI对话工具，商量商量，都能解决。
36 查看详情
核心思想是：将原始数据（而不是已启动的 Promise）传递给 Bluebird.map，并在 map 的迭代器函数中按需启动每个网络请求。这样，concurrency 选项才能真正限制同时进行的请求数量。
import BlueBirdPromise from 'bluebird'; // 确保已安装 bluebirdconst retry = async (requests: API.CarFailedRequest[]) => { setIsLoading(true); await BlueBirdPromise.map( requests, // 直接传入原始的请求数据数组 async request => { // 在这里，当 Bluebird.map 允许时，才启动请求 try { await service.retryFailedRequest(request); // 可以根据需要返回状态或数据 return { status: true, request }; } catch (err) { console.error("请求失败:", request, err); // 返回失败状态，或者根据错误类型进行重试 return { status: false, request, error: err }; } }, { concurrency: 10 } // 同时只允许 10 个请求处于活跃状态 ); setIsLoading(false); // 返回处理结果，Bluebird.map 默认会返回一个包含所有迭代器返回值的数组 // 例如：const results = await BlueBirdPromise.map(...) // return results;};
代码解析：
BlueBirdPromise.map(requests, async request => {…}, { concurrency: 10 })：第一个参数 requests 是原始的数据数组，每个元素代表一个待处理的请求。第二个参数是一个 async 函数，它会在 Bluebird.map 内部按并发限制逐个调用。在这个函数内部，await service.retryFailedRequest(request) 才会真正发起网络请求。{ concurrency: 10 } 是关键。它告诉 Bluebird 在任何给定时间，最多只能有 10 个 async request => {…} 函数在执行（即最多 10 个网络请求同时进行）。当一个请求完成时，Bluebird 会从队列中取出下一个请求并启动它，直到所有请求都被处理完毕。
这种方法确保了网络请求是分批、有控制地发出的，从而有效避免了API限流和超时问题。
解决方案二：手动实现分批与延迟（更精细控制）
如果不想引入 Bluebird 库，或者需要对分批和延迟有更精细的控制，可以手动实现一个分批处理函数。关键在于，我们需要传递的是返回 Promise 的函数，而不是已经启动的 Promise。
/** * 按批次处理异步任务，并在批次之间添加延迟。 * @param taskFns 数组，每个元素是一个返回 Promise 的函数。 * @param chunkSize 每批处理的任务数量。 * @param delayMs 每批次之间的延迟时间（毫秒）。 * @returns 所有任务完成后的结果数组。 */const processTasksInChunksWithDelay = async ( taskFns: (() => Promise)[], chunkSize: number, delayMs: number): Promise => { const results: T[] = []; for (let i = 0; i fn()); const chunkResults = await Promise.all(chunkPromises); results.push(...chunkResults); // 如果还有后续批次，则进行延迟 if (i + chunkSize setTimeout(resolve, delayMs)); } } return results;};const retryWithManualChunks = async (requests: API.CarFailedRequest[]) => { setIsLoading(true); // 将每个请求封装成一个返回 Promise 的函数 const requestTaskFns = requests.map(request => async () => { try { await service.retryFailedRequest(request); return { status: true, request }; } catch (e) { console.error("请求失败:", request, e); return { status: false, request, error: e }; } }); // 调用分批处理函数，每5个请求一批，每批之间延迟5秒 const allResults = await processTasksInChunksWithDelay(requestTaskFns, 5, 5000); setIsLoading(false); return allResults;};
代码解析：
requestTaskFns 数组中存储的不再是已启动的 Promise，而是函数。每个函数在被调用时才会返回一个 Promise（即发起网络请求）。processTasksInChunksWithDelay 函数在循环中，每次只取出 chunkSize 个函数。chunkFns.map(fn => fn()) 在这里才真正调用这些函数，启动对应批次的网络请求。await Promise.all(chunkPromises) 等待当前批次的所有请求完成。await new Promise(resolve => setTimeout(resolve, delayMs)) 在批次之间添加了明确的延迟。
这种手动实现方式提供了极大的灵活性，可以精确控制每批次的请求数量和批次间的延迟时间，适用于需要严格遵守API速率限制的场景。
最佳实践与注意事项
选择合适的并发数/批次大小和延迟：没有一劳永逸的完美值。这取决于你的后端API的承载能力、速率限制以及用户对响应速度的期望。通常需要通过实验和监控来确定最佳参数。完善的错误处理与重试机制：在每个请求的 try…catch 块中捕获错误。对于可重试的错误（如 429, 5xx），可以实现指数退避（exponential backoff）的重试逻辑。记录失败的请求，以便后续分析或手动处理。用户体验考虑：在大量请求处理期间，提供加载指示器 (setIsLoading(true))，避免用户误以为应用无响应。对于长时间运行的任务，考虑使用Web Workers将网络请求逻辑放到后台线程，避免阻塞主线程。监控与日志：在开发和生产环境中，密切监控网络请求的数量、成功率和响应时间。通过日志记录请求失败的详细信息，有助于快速定位问题。API 设计优化：如果可能，与后端团队协作，探讨是否可以提供批量处理API，从而将多个小请求合并为一个大请求，从根本上减少网络往返次数。
总结
处理大量网络请求是前端开发中的常见挑战。通过本文的探讨，我们了解到直接使用 Promise.all 可能会导致API超时和资源耗尽。关键在于控制请求的启动时机。无论是利用 Bluebird.map 的 concurrency 选项，还是手动实现分批处理和延迟，核心原则都是将大量请求分解为可管理的批次，并控制每个批次内的并发数以及批次间的间隔。通过采纳这些策略并结合最佳实践，开发者可以构建出更健壮、更高效、用户体验更好的应用。
以上就是优化大量网络请求：分批处理、并发控制与超时策略的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/302454.html
微信扫一扫 
支付宝扫一扫 
