JavaScript Promise.all 失败后为什么其他请求仍可能继续

页面同时加载用户资料、权限和推荐列表时，Promise.all() 只会告诉你“这一组结果不能整体使用”，不会替你取消已经启动的请求。某一个 Promise 先 reject 后，其他 fetch 仍可能继续传输、解析，甚至在自己的回调里修改状态。要真正停止它们，必须把取消信号传给每个请求，再用批次编号挡住迟到响应。

官方地址：https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

先分清 Promise.all 的失败边界

Promise.all([a, b, c]) 在任意输入拒绝时立即拒绝，并把第一个拒绝原因交给调用方；这只是聚合 Promise 的状态变化。a、b、c 早已分别开始执行，聚合失败不会撤回它们已经发出的网络请求，也不会自动终止定时器、流读取或自定义异步任务。

因此，看到“页面已经进入 catch，但网络面板还有请求完成”并不矛盾。先记录每个任务的开始、成功、失败和取消，再决定是否需要取消；如果只是想拿到所有结果而允许部分失败，应考虑 Promise.allSettled()，不要用取消去掩盖业务上的部分可用。

用共享 AbortController 让取消信号到达每个请求

对于可取消的 Web API，常见做法是一次批次创建一个控制器，把它的 signal 交给所有 fetch。任一请求发生不可继续的错误时，先调用 controller.abort()，再让外层等待聚合 Promise 的结果。示例中的注释说明了取消原因和清理边界：

async function loadDashboard(urls) {
  // 一个批次只创建一个控制器，让所有 fetch 共享取消信号。
  const controller = new AbortController();
  const { signal } = controller;

  const tasks = urls.map((url) =>
    fetch(url, { signal }).then((response) => {
      // HTTP 失败不会自动 reject，显式抛出便于 Promise.all 统一处理。
      if (!response.ok) throw new Error(`HTTP ${response.status}: ${url}`);
      return response.json();
    }),
  );

  try {
    return await Promise.all(tasks);
  } catch (error) {
    // 失败意味着本批结果不可用，协作取消仍未结束的请求。
    controller.abort();
    if (error.name === "AbortError") throw error;
    throw error;
  }
}

这里的关键不是把 AbortController 放进 Promise.all，而是把同一个 signal 传进每一个可取消操作。取消后通常会得到名称为 AbortError 的拒绝；它代表用户切页、主动重试或批次清理，不一定代表服务器故障。生产代码应把它和真正的 HTTP、解析、权限错误分开记录。

用请求代次挡住旧批次的迟到结果

abort() 是协作式通知，不能抹掉已经进入浏览器队列、缓存或业务回调的所有工作。页面快速切换筛选条件时，旧批次即使被取消，也可能在取消前完成。为每次加载分配递增的 generation，只有仍属于当前批次的结果才允许写入状态：

let currentGeneration = 0;
let activeController = null;

async function refreshPanel(filters, render) {
  // 新批次先取消旧批次，并用代次识别迟到结果。
  activeController?.abort();
  const controller = new AbortController();
  activeController = controller;
  const generation = ++currentGeneration;

  try {
    const result = await loadDashboard(buildUrls(filters), controller.signal);
    // 取消状态与代次都要检查，防止旧请求覆盖新界面。
    if (controller.signal.aborted || generation !== currentGeneration) return;
    render(result);
  } catch (error) {
    // 用户主动切换条件不应显示成红色业务错误。
    if (error.name !== "AbortError" && generation === currentGeneration) {
      render({ error });
    }
  } finally {
    // 只清理自己持有的控制器，避免误删新批次的引用。
    if (generation === currentGeneration) activeController = null;
  }
}

上例中 loadDashboard 需要改为接收外部 signal，或者由调用方直接创建任务；不要在内部无条件新建控制器，否则外层的取消信号无法传进去。对于非 fetch 的任务，则要在任务实现中主动监听 signal.aborted，并在合适的清理点停止工作。

按业务选择 all、allSettled 与可取消策略

选择组合器前先问一个问题：这组请求是“必须全部成功”还是“尽量收集可用结果”？前者可以使用 Promise.all，失败后通过共享信号结束剩余请求；后者使用 Promise.allSettled，让页面分别展示成功卡片和失败卡片，但仍可在用户离开页面时主动取消。

排查时至少覆盖四个场景：一个请求立刻失败、一个请求慢速完成、用户连续切换两次筛选、组件卸载后仍有响应返回。检查网络层是否收到取消、日志是否把 AbortError 与服务端错误分开、状态层是否验证代次。只有“聚合失败、底层任务取消、旧结果不回写”三件事同时成立，才算完成了并发请求的取消设计。

常见问题

Promise.all 失败后还能拿到其他请求的结果吗？

底层请求可能仍会完成，但聚合 Promise 不会再返回完整数组。若要逐项读取成功或失败，请改用 Promise.allSettled 或为每项单独处理。

调用 abort() 后服务器一定停止处理吗？

不一定。它主要通知浏览器和客户端停止等待或传输，服务器已接收的请求可能已经进入处理流程，服务端仍需自己的取消或幂等设计。

为什么用了 AbortController 还会出现旧数据？

取消是异步协作，响应可能在取消前完成。提交状态前增加批次编号或请求 token 检查，才能拦住迟到结果。

把 Promise.all 看成“结果聚合器”，把 AbortController 看成“取消通道”，再用代次检查保护 UI，三者职责分开后，并发请求的失败、重试和切页行为就更容易解释和测试。