Array.fromAsync 不适合处理大型异步任务，因其必须等待全部异步项完成才返回数组，缺乏流式消费、内存节制、暂停取消、错误部分恢复及并发控制能力，推荐改用 for await...of 配合 p-limit 或 ReadableStream 分批处理。
Array.fromAsync 不适合处理大型异步任务，核心问题在于它必须等待全部异步项完成才返回数组，缺乏流式消费和内存节制能力。
必须全量等待，无法增量处理
Array.fromAsync 内部会遍历整个异步可迭代对象，逐个 await 每一项，直到迭代结束才 resolve Promise。这意味着：
- 对成千上万条记录的数据库游标或文件流，它会把所有结果暂存在内存中，容易触发内存溢出
- 用户无法在首批数据就绪后就开始渲染或转发，必须“等到底”才能拿到数组
- 没有暂停、取消或中断机制，一旦启动就不可控
错误传播是“全有或全无”
只要异步迭代过程中任意一次 yield 抛出错误（比如某页 API 返回 500），Array.fromAsync 就立刻 reject，前面已成功获取的数据全部丢失：
- 无法像 Promise.allSettled 那样保留部分成功结果
- 也不支持跳过失败项继续迭代（除非在异步生成器内部做 try/catch 包裹）
- 重试逻辑需完全由源迭代器自行实现，Array.fromAsync 不提供重试钩子
不支持并发控制
它按顺序逐项 await，无法并行发起多个请求：
立即学习“Java免费学习笔记（深入）”；
- 即使你 yield 的是并发 fetch 调用，Array.fromAsync 本身不控制并发数，实际并发量取决于生成器内部逻辑
- 若生成器未做限流（如没用 p-limit 包装），可能瞬间发出数百请求，压垮服务端或触发浏览器限制
- 无法指定最大并发数、超时、退避等生产环境必需参数
替代方案更灵活
面对大批量异步数据，推荐更可控的方式：
- 用 for await...of 手动遍历异步迭代器，边取边处理，及时释放内存
- 配合 p-limit 控制并发，用 Promise.all 处理分块任务
- 对流式场景（如 ReadableStream），直接使用 readableStream.getReader() + read() 分批读取
- 需要聚合结果时，自己维护数组并 push，而非依赖一次性 fromAsync
