Promise.allSettled适合导出任务成败分离处理，因其不中断执行、返回所有任务终态，兼顾并发、结果不丢失与错误可追溯；需绑定上下文、分批控制并发并显式处理响应错误。
Promise.allSettled 为什么适合导出任务的成败分离处理
因为 Promise.allSettled 不会因某一项 reject 而中断，它始终返回所有 Promise 的最终状态（fulfilled 或 rejected），这正好匹配导出场景：你不需要“全成功才继续”，而是要逐条知道“哪个文件导出失败、失败原因是什么、成功的结果在哪”。
对比 Promise.all（一错全停）和手写 try/catch + for...of（串行慢、难并发控制），Promise.allSettled 是唯一能兼顾「并发执行」+「结果不丢失」+「错误可追溯」的原生方案。
如何构造每个导出任务并保留上下文信息
直接传入裸 fetch 或 axios 调用会导致结果里丢失“这是导出哪条数据”的标识。必须把原始参数（如 id、filename）和 Promise 封装绑定。
- 用
map遍历任务列表，对每一项返回一个带上下文的 Promise： - Promise 内部捕获异常，并在
reject时把原始参数和错误一起抛出； - 成功时也把原始参数和响应结果一并
resolve，避免后续还要靠索引对齐。
示例：
const tasks = items.map(item =>
fetch(`/api/export?id=${item.id}`)
.then(res => res.blob())
.then(blob => ({ status: 'fulfilled', item, result: blob }))
.catch(err => ({ status: 'rejected', item, error: err }))
);
Promise.allSettled 返回值怎么分类提取成功/失败详情
Promise.allSettled 返回的是形如 [{status: 'fulfilled', value: ...}, {status: 'rejected', reason: ...}] 的数组，但注意：它不会把我们上面手动包装的 {status, item, result} 当作 value —— 因为那是我们 resolve 的值，而 allSettled 的 value 字段只存在于 fulfilled 项中，reason 只存在于 rejected 项中。
- 别直接解构
value或reason，先判断status； - 成功项的原始参数和结果都在
value里（因为我们 resolve 的是对象）； - 失败项的原始参数和错误也在
reason里（因为我们 reject 的也是对象）； - 用
filter+map分离更清晰，比如：results.filter(r => r.status === 'fulfilled').map(r => r.value)。
并发数量控制不当会导致 429 或内存溢出
Promise.allSettled 本身不控制并发数，如果一次性扔进去 500 个 fetch，浏览器大概率触发请求限流（429 Too Many Requests）或卡死标签页。必须做节流。
- 不要用
Promise.allSettled(tasks)一股脑提交； - 改用分批（batch）方式：每批最多 10 个，用
for循环 +await Promise.allSettled(batch)； - 每批之间加
await new Promise(r => setTimeout(r, 0))防止微任务堆积； - 服务端导出接口最好支持
Accept: text/csv或流式响应，避免大文件全加载进内存再blob()。
真正容易被忽略的是：即使用了 allSettled，错误对象里的 error.stack 或 err.response?.data 可能为空——因为网络层（如 axios）默认不透传响应体到 rejection 原因里，得显式配置 validateStatus: () => true 并手动检查 response.status 才能拿到后端返回的具体错误码和消息。
