JavaScript Promise.allSettled和all在部分失败时的处理差异

JavaScript Promise.allSettled和all在部分失败时的处理差异

在编写处理多个并发异步操作的代码时，Promise.all 和 Promise.allSettled 是两个常用且强大的工具。它们看似功能相似，但在处理部分请求失败的场景下，行为截然不同。理解这一差异，是写出健壮、可预测代码的关键。

核心概念：何为“部分失败”？

想象一个典型场景：你需要同时向三个不同的API接口请求数据。如果一切顺利，三个请求都成功，那么结果就是一组完整的数据。但实际情况中，可能会有一个接口暂时无法访问，导致对应的请求失败。这就是“部分失败”。

接下来，我们分别看看 Promise.all 和 Promise.allSettled 在这种情况下会如何表现。

使用 Promise.all：一个失败，全体拒绝

Promise.all 的逻辑非常严格：它要求传入的所有 Promise 都必须成功，它自己才会成功。

1. 创建 一个包含多个 Promise 的数组，模拟三个数据请求，其中一个会失败。

// 模拟成功1秒后返回数据的请求
function fetchDataA() {
    return new Promise((resolve) => {
        setTimeout(() => resolve({ id: 1, data: '数据A' }), 1000);
    });
}

// 模拟成功1秒后返回数据的请求
function fetchDataB() {
    return new Promise((resolve) => {
        setTimeout(() => resolve({ id: 2, data: '数据B' }), 1000);
    });
}

// 模拟一个立即失败的请求
function fetchDataC() {
    return new Promise((resolve, reject) => {
        setTimeout(() => reject(new Error('请求C失败：服务器无响应')), 500);
    });
}

2. 调用 Promise.all 并观察 其结果。

const promises = [fetchDataA(), fetchDataB(), fetchDataC()];

Promise.all(promises)
    .then(results => {
        // 代码永远不会执行到此处，因为 promiseC 被拒绝了
        console.log('全部成功:', results);
    })
    .catch(error => {
        // 代码会立即进入这个分支
        // 但只能捕获到第一个失败的错误（即来自 fetchDataC 的错误）
        console.error('存在失败:', error.message); // 输出：请求C失败：服务器无响应
    });

关键行为：Promise.all 返回的“主Promise”会在第一个子 Promise 被拒绝时，立即 被拒绝。你无法得知其他子 Promise 的状态（它们可能还在执行，或者已经成功），也无法获取任何成功的子 Promise 的结果。它的设计哲学是全有或全无。

使用 Promise.allSettled：耐心等待，无论成败

Promise.allSettled 的逻辑则更具包容性：它会等待所有传入的 Promise 都 “敲定”（settled）——即无论最终状态是成功（fulfilled）还是失败（rejected），都算敲定。

1. 使用 同样的 Promise 数组。

2. 调用 Promise.allSettled 并检查 其结果结构。

const promises = [fetchDataA(), fetchDataB(), fetchDataC()];

Promise.allSettled(promises)
    .then(results => {
        // 代码总会执行到此处，等待所有Promise敲定
        console.log('所有操作已完成');
        console.log(results);
    });

上述代码中，results 会是一个数组，其顺序与传入的 promises 数组一致，每个元素都是一个描述对象，有两种可能的状态：

• 成功时：{ status: 'fulfilled', value: 成功的结果 }
• 失败时：{ status: 'rejected', reason: 失败的错误对象 }

对于我们的示例，results 数组可能如下所示（为清晰起见，对输出进行了格式化）：

[
  { status: 'fulfilled', value: { id: 1, data: '数据A' } },
  { status: 'fulfilled', value: { id: 2, data: '数据B' } },
  { status: 'rejected', reason: Error: 请求C失败：服务器无响应 }
]

关键行为：Promise.allSettled 返回的“主Promise”永远不会被拒绝。它总是会等待所有子 Promise 运行结束，并为你提供一份完整的“成绩单”，上面清晰地记录了每个子任务是成功了还是失败了。

两种方法的核心差异对比

通过下表，可以更直观地理解它们的区别：

如何选择：一个实用的决策流程

根据你的具体业务逻辑，遵循以下步骤选择：

1. 判断 你的场景是否要求所有任务都必须成功。

   • 是 -> 使用 Promise.all。例如：同时读取多个关键配置文件，缺少任何一个都无法继续程序启动。
   • 否 -> 进入下一步。

2. 判断 你是否需要等到所有任务结束再统一处理。

   • 是 -> 使用 Promise.allSettled。例如：批量上传10个文件，你需要在最后生成一份报告，说明8个成功、2个失败及其原因，而不会因为第一个失败就中断整个上传队列。
   • 否 -> 可能你需要的是 Promise.any（等待第一个成功）或 Promise.race（等待第一个敲定）。

3. 组合使用的场景。

   • 在需要 Promise.allSettled 的包容性，但又希望对成功结果进行快速处理时，你可以这样写：

Promise.allSettled(promises)
    .then(results => {
        const successfulResults = results
            .filter(result => result.status === 'fulfilled')
            .map(result => result.value);

        const failedReasons = results
            .filter(result => result.status === 'rejected')
            .map(result => result.reason);

        console.log('成功获取:', successfulResults);
        console.warn('以下请求失败:', failedReasons);

        // 根据 successfulResults 进行后续业务逻辑
        if (successfulResults.length > 0) {
            processPartialData(successfulResults);
        } else {
            showError('无有效数据');
        }
    });

总结：Promise.all 是严格的指挥官，要求全员达标；Promise.allSettled 是耐心的记录员，如实汇报每个人的战况。根据你对“失败”的容忍度和对“结果完整性”的需求，选择合适的工具。