promise.allsettled用于等待所有promise完成（无论成功或失败），并返回结果数组。它会收集每个promise的status、value（fulfilled时）或reason（rejected时）。1. 它不会因某个promise被拒绝而中断整体流程；2. 返回的结果数组中每个对象都包含对应promise的最终状态和数据；3. 适用于需要获取所有异步任务执行结果（包括失败）的场景，如批量操作、多源数据聚合等；4. 可通过遍历、过滤、归类等方式处理结果，便于日志记录、错误统计和后续逻辑处理。
JavaScript中的Promise.allSettled方法，是用来等待一组Promise都达到“已决”状态（fulfilled 或 rejected）后，才返回一个包含每个Promise结果状态的对象数组。这意味着无论每个Promise是成功还是失败，你都能得到它的最终信息，而不会因为其中一个Promise的失败而立即中断整个操作。它提供了一种更健壮的方式来处理并发的异步任务，尤其当你关心所有任务的独立结果时。
解决方案
Promise.allSettled接收一个Promise可迭代对象（通常是数组），并返回一个新的Promise。这个新的Promise在所有输入的Promise都已决时解析，解析的值是一个数组，数组中的每个元素都描述了对应Promise的最终状态。
每个状态对象都有一个status属性，值为'fulfilled'或'rejected'。
如果状态是'fulfilled'，对象会有一个value属性，包含Promise的成功值。
如果状态是'rejected'，对象会有一个reason属性，包含Promise的拒绝原因。
const promise1 = Promise.resolve(3);
const promise2 = new Promise((resolve, reject) => setTimeout(reject, 100, '出错了！'));
const promise3 = Promise.resolve(42);
const promise4 = new Promise((resolve) => setTimeout(resolve, 50, 'Hello'));
Promise.allSettled([promise1, promise2, promise3, promise4])
.then((results) => {
console.log('所有Promise都已决：', results);
// 示例输出:
// [
// { status: 'fulfilled', value: 3 },
// { status: 'rejected', reason: '出错了！' },
// { status: 'fulfilled', value: 42 },
// { status: 'fulfilled', value: 'Hello' }
// ]
results.forEach((result, index) => {
if (result.status === 'fulfilled') {
console.log(`Promise ${index + 1} 成功，值为: ${result.value}`);
} else {
console.error(`Promise ${index + 1} 失败，原因为: ${result.reason}`);
}
});
})
.catch((error) => {
// Promise.allSettled的Promise本身不会被拒绝，除非传入的不是可迭代对象
console.error('发生了一个意料之外的错误:', error);
});这个方法特别适合那些你希望所有并发操作都能跑完，并且需要对每个操作的结果进行详细记录或展示的场景。我个人在使用它的时候，感觉就像是拿到了一份完整的“任务执行报告”，成功失败一目了然，非常省心。
立即学习“Java免费学习笔记（深入）”；
Promise.allSettled与Promise.all、Promise.race有何不同？
理解Promise.allSettled的独特之处，需要把它和另外两个常用的Promise组合方法——Promise.all和Promise.race——放在一起比较。它们各自有不同的应用场景和行为模式，选错一个，可能整个异步流程就跑偏了。
Promise.all是最严格的。它接收一组Promise，并且只有当所有Promise都成功（fulfilled）时，它返回的Promise才会成功，并返回一个包含所有成功值的数组。但如果这组Promise中，哪怕只有一个Promise失败（rejected）了，Promise.all就会立即拒绝，并返回第一个拒绝的原因。它是一个“全有或全无”的策略，适用于所有任务都必须成功才能继续的场景，比如多个数据都加载成功才渲染页面。我经常用它来确保一个组件所需的所有数据都到位了，才开始渲染，任何一个数据缺失都会导致渲染失败。
Promise.race则截然不同。它也接收一组Promise，但它只关心“最快”的那个。只要这组Promise中有一个Promise率先达到已决状态（无论是成功还是失败），Promise.race返回的Promise就会立即以那个Promise的结果（成功值或失败原因）来解析或拒绝。它就像一场赛跑，谁先到终点，谁就决定了最终结果。这在比如设置超时机制时非常有用，你可以让一个请求Promise和一个定时器Promise一起赛跑，如果定时器先完成（超时），就拒绝请求。
而Promise.allSettled，它不追求“全成功”，也不追求“最快”，它追求的是“全知”。它会等待所有传入的Promise都尘埃落定（settled），无论是成功还是失败，它都会收集每个Promise的最终状态和结果（或原因），然后返回一个包含这些详细信息的数组。这个数组里的每个对象都明确告诉你，对应的Promise是成功了，成功值是什么；还是失败了，失败原因是什么。我发现，在需要确保所有操作都尝试执行，并且我关心每个操作的最终状态时，allSettled简直是救星。不像all那样，一个失败就全盘皆输，allSettled给我提供了一个完整的“战报”，让我能基于这份报告做后续的错误处理、日志记录或者部分成功展示。
在实际项目中，何时优先考虑使用Promise.allSettled？
在我的实际开发经验中，Promise.allSettled的出场频率，虽然不如Promise.all那么高，但在特定场景下，它几乎是不可替代的。我通常会在以下几种情况中优先考虑使用它：
大小仅1兆左右 ，足够轻便的商城系统； 易部署，上传空间即可用，安全，稳定； 容易操作，登陆后台就可设置装饰网站； 并且使用异步技术处理网站数据，表现更具美感。 前台呈现页面，兼容主流浏览器，DIV+CSS页面设计； 如果您有一定的网页设计基础，还可以进行简易的样式修改，二次开发， 发布新样式，调整网站结构，只需修改css目录中的css.css文件即可。 商城网站完全独立，网站源码随时可供您下载
一个很典型的例子是批量操作。想象一下，你需要向服务器发送一批用户通知，或者批量更新一组用户数据。这里面可能有些用户ID是无效的，或者某些更新操作因为权限问题会失败。如果用Promise.all，一旦有一个通知发送失败，整个批处理就会中断，你可能就无法得知其他通知是否成功发送了。而使用Promise.allSettled，你可以确保所有的通知发送尝试都会完成，然后你就能得到一份详尽的报告：哪些通知成功了，哪些失败了，失败的原因是什么。这对于后续的重试、错误日志记录或者给用户反馈“部分成功”的消息至关重要。
另一个场景是多源数据聚合与展示。比如，你的前端页面需要从多个独立的API接口获取数据来填充不同的模块。这些API可能由不同的团队维护，或者它们的稳定性不一。你希望即使某个API调用失败了，页面上的其他模块也能正常显示数据，而不是整个页面都崩溃或者显示一个空白。用Promise.allSettled，你可以并行发起所有请求，然后根据每个请求的结果，决定是渲染对应模块的数据，还是显示一个友好的错误提示。这样用户体验会好很多，不会因为一个接口的小问题就影响到整个页面的可用性。
我常常在做一些后台任务调度时用到它。比如，我要给一批用户发送通知，有些用户可能已注销，有些邮箱无效，我不可能因为一个失败就停止整个批处理。allSettled让我能优雅地处理这些边缘情况，并生成一份详细的执行报告。我甚至会用它来做一些前端的“健康检查”，同时请求多个关键资源，然后根据allSettled的结果来判断哪些资源加载失败了，并进行相应的处理。它提供的那种“即使有失败，我也要知道所有情况”的哲学，在很多业务场景下都显得非常实用。
如何优雅地处理Promise.allSettled返回的结果？
处理Promise.allSettled返回的结果，其实就是一次数据清洗和分类的过程。由于它返回的是一个包含状态和值的数组，我们需要遍历这个数组，根据每个元素的status属性来区分成功和失败，并提取相应的数据。
最直接的方式是使用forEach或for...of循环遍历结果数组：
async function processAllTasks() {
const tasks = [
Promise.resolve('数据A加载成功'),
Promise.reject(new Error('数据B加载失败：网络错误')),
new Promise(res => setTimeout(() => res('数据C准备就绪'), 200)),
Promise.reject('数据D加载失败：权限不足')
];
const results = await Promise.allSettled(tasks);
console.log('--- 任务处理报告 ---');
results.forEach((item, index) => {
if (item.status === 'fulfilled') {
console.log(`任务 ${index + 1} (成功): ${item.value}`);
// 可以在这里更新UI、存储成功数据等
} else {
console.error(`任务 ${index + 1} (失败): ${item.reason}`);
// 可以在这里记录日志、显示错误消息、触发重试等
}
});
// 统计成功和失败的数量
const fulfilledCount = results.filter(item => item.status === 'fulfilled').length;
const rejectedCount = results.filter(item => item.status === 'rejected').length;
console.log(`\n总任务数: ${results.length}, 成功: ${fulfilledCount}, 失败: ${rejectedCount}`);
}
processAllTasks();这种遍历方式非常直观，能让你对每个任务的最终状态进行细致的处理。
更进一步，如果你想把成功和失败的结果分别归类，或者进行更复杂的数据转换，可以使用数组的map或reduce方法。比如，我有时候会把成功的结果提取出来放到一个数组，失败的结果及其原因放到另一个数组，方便后续统一处理：
async function categorizeResults() {
const requests = [
fetch('https://api.example.com/data1').then(res => res.json()), // 假设成功
fetch('https://api.example.com/data2').then(res => res.json()), // 假设失败
fetch('https://api.example.com/data3').then(res => res.json()) // 假设成功
];
const allOutcomes = await Promise.allSettled(requests);
const successfulData = allOutcomes
.filter(outcome => outcome.status === 'fulfilled')
.map(outcome => outcome.value);
const failedReasons = allOutcomes
.filter(outcome => outcome.status === 'rejected')
.map(outcome => outcome.reason);
console.log('\n--- 分类处理后的结果 ---');
console.log('成功获取的数据:', successfulData);
console.log('失败的原因:', failedReasons);
// 甚至可以进一步处理失败原因，比如统计错误类型
const errorMap = failedReasons.reduce((acc, reason) => {
const errorMessage = reason instanceof Error ? reason.message : String(reason);
acc[errorMessage] = (acc[errorMessage] || 0) + 1;
return acc;
}, {});
console.log('错误类型统计:', errorMap);
}
// 模拟fetch请求，以展示allSettled的实际效果
// 在实际运行中，需要替换为真实的API请求或模拟Promise行为
function fetch(url) {
return new Promise((resolve, reject) => {
if (url.includes('data2')) {
setTimeout(() => reject(new Error(`Failed to fetch ${url}`)), 50);
} else {
setTimeout(() => resolve({ json: () => Promise.resolve({ source: url, content: 'some data' }) }), 50);
}
});
}
categorizeResults();处理allSettled的结果，关键在于它的结构化输出。这给了我们极大的灵活性去定制后续的逻辑，无论是仅仅打印日志、更新UI，还是触发更复杂的业务流程，都能做到既全面又精准。我通常会把成功和失败的分别归类，有时候还会用reduce来统计成功的数量和失败的原因分布，这样一眼就能看出整体情况。这比单纯地打印出来要有用得多，尤其是在调试或者做数据分析的时候。
