17370845950

Promise.all 一错全崩因其设计契约是“全部成功才算成功”，适用于强依赖场景；需容错用 allSettled，防竞态需 AbortController 等机制，而非仅靠 race。

Promise.all 不适合处理有失败容忍需求的场景，它只要一个 rejected 就整个失败；竞态条件（race condition）在并发请求中真实存在，但 Promise.race 本身不解决竞态，只是暴露它。

Promise.all 为什么一错就全崩？

Promise.all 的设计目标是“全部成功才算成功”，任何一项 reject 都会立即终止并抛出错误。这不是 bug，是契约——它假设你依赖所有结果协同工作（比如同时拉取用户信息、权限列表、配置项，缺一不可）。

常见误用：拿它批量发日志上报、埋点、非关键接口调用，结果因某条网络抖动导致主流程中断。

• 想“尽量完成，忽略个别失败” → 改用 Promise.allSettled
• 想“只取最快响应，其余取消” → 需配合 AbortController 或封装 cancelable promise
• 想“失败后 fallback 到默认值” → 单个 Promise 内部用 .catch() 处理，再传入 Promise.all

Promise.allSettled 是更安全的批量执行选择

Promise.allSettled 不关心成功或失败，等所有 Promise 进入 settled 状态（即 fulfilled 或 rejected）后统一返回数组，每个元素带 status 字段。

适合场景：批量校验、多源数据采集、非强依赖的预加载。

const requests = [
  fetch('/api/user'),
  fetch('/api/config').catch(() => ({ ok: false, status: 503 })),
  fetch('/api/feature-flag')
];

Promise.allSettled(requests)
  .then(results => {
    results.forEach((result, i) => {
      if (result.status === 'fulfilled') {
        console.log(`Request ${i} succeeded:`, result.value);
      } else {
        console.warn(`Request ${i} failed:`, result.reason);
      }
    });
  });

竞态条件不是 Promise.race 能“解决”的问题

Promise.race 只是返回第一个 settled 的 Promise 结果，它不取消其他 Promise，也不感知业务语义。真正的竞态发生在“多个异步操作修改同一状态”时，例如：用户快速连续点击提交按钮，触发两次 fetch，后发先至的响应覆盖了先发后至的数据（UI 显示旧数据）。

关键点：

• Promise.race([p1, p2]) 不等于“让 p2 取消 p1”
• 浏览器原生 fetch 支持 signal，但需手动传入 AbortController
• React/Vue 等框架中，组件卸载后仍更新 state 是典型竞态，应检查 isMounted 或用 useEffect 清理函数

简易防竞态封装示例（基于 AbortController）：

function fetchWithRace(url, { signal } = {}) {
  const controller = new AbortController();
  const raceSignal = signal || controller.signal;

  return fetch(url, { signal: raceSignal })
    .catch(err => {
      if (e
rr.name === 'AbortError') throw new Error('Canceled by race');
      throw err;
    });
}

// 使用：后一次调用自动 abort 前一次
let currentAbortController;
async function loadData(id) {
  currentAbortController?.abort();
  currentAbortController = new AbortController();
  return fetchWithRace(`/api/item/${id}`, {
    signal: currentAbortController.signal
  });
}

真正要警惕的是状态覆盖和生命周期错配

比 Promise 组合方式更常引发线上问题的，是异步回调与 UI 生命周期脱节。例如在 React 中：

• 组件已 unmount，但 fetch.then(setData) 仍执行 → 报 Warning，且可能污染其他组件状态
• 多次快速搜索，每次请求返回顺序不确定 → 用户看到的不是最后一次输入对应的结果
• 使用 Promise.all 并行请求 A/B/C，但只用 C 的结果更新 UI，却没处理 A/B 失败对 C 的影响逻辑

这些都不是换一个 Promise API 就能绕开的。需要结合信号控制（AbortController）、状态标记（isLatestRef）、或框架提供的异步管理能力（如 React Query 的 queryKey 自动去重和取消）。