Fetch AbortSignal.any 合并多个取消来源的处理

一个 Fetch 请求常常同时受三类事件影响：用户点击取消、请求超过时限、页面或组件离开。把这些事件分别写进每个请求会让错误处理越来越散。更稳妥的做法是为每个来源保留独立的 AbortSignal，再用 AbortSignal.any() 合并成一个信号传给 fetch()。

官方地址：https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/any_static

核心规则是“任一来源先终止，合并信号就终止”，合并信号的 reason 取触发它的第一个来源；但它不会反向取消其他来源，也不会替你清理业务代码添加的监听器。

一、先拆出用户取消与超时来源

组合前不要急着创建一个“万能控制器”。用户操作和时间限制是两个不同事实：前者由页面事件触发，后者由计时器触发。保留两条来源，后面才能解释请求为什么结束，也能避免误以为取消合并信号会连带改变所有来源。

const userController = new AbortController();

// 超时信号只负责时间边界，不会替用户控制器调用 abort()
const timeoutSignal = AbortSignal.timeout(8000);

// 任一来源终止，combinedSignal 就会终止
const combinedSignal = AbortSignal.any([
  userController.signal,
  timeoutSignal,
]);

// 例如按钮事件只取消用户来源
const cancelButton = document.querySelector("#cancelButton");
cancelButton.addEventListener("click", () => {
  userController.abort(new DOMException("用户主动取消", "AbortError"));
});

如果数组里已经有一个处于 aborted 状态的信号，返回的信号会立即处于 aborted 状态。因此在发起请求前要确认来源是否可能被复用；一个已经取消的信号不能拿来开启下一次独立请求。

二、把合并信号传给 Fetch

fetch() 和响应体读取都应处在同一个取消语义里。下面的写法把合并信号传入请求选项，并在读取正文时继续等待，避免“请求头到了但正文仍在占用资源”的半截状态。

async function loadProfile(url) {
  const userController = new AbortController();
  const timeoutSignal = AbortSignal.timeout(8000);
  const signal = AbortSignal.any([
    userController.signal,
    timeoutSignal,
  ]);

  // 真实页面中可把这个函数绑定到取消按钮
  const cancel = () => userController.abort(
    new DOMException("用户主动取消", "AbortError"),
  );
  const cancelButton = document.querySelector("#cancelButton");
  cancelButton?.addEventListener("click", cancel);

  try {
    const response = await fetch(url, { signal });
    if (!response.ok) {
      // HTTP 404/500 仍是 Response，不等同于取消
      throw new Error(`HTTP ${response.status}`);
    }
    // 继续使用同一取消链读取响应体
    return await response.json();
  } finally {
    // 示例中若把 cancel 注册到按钮，应在这里解除注册
    cancelButton.removeEventListener("click", cancel);
  }
}

上例的关键不是把所有异常都吞掉，而是让取消链的入口统一。HTTP 错误要看 response.ok；网络错误和取消则进入 catch。不要因为看到 fetch() 抛错，就把服务器返回的 500 也提示成“请求超时”。

三、按 reason 和错误名处理结果

合并信号不会额外提供“来源名称”字段，它只保留第一个终止来源的 reason。如果需要给用户不同提示，应在手动取消时传入明确原因，并对超时信号和合并信号分别保留引用。

try {
  const data = await loadProfile("/api/profile");
  renderProfile(data);
} catch (error) {
  // 用户取消通常是 AbortError，超时通常是 TimeoutError
  if (error?.name === "AbortError") {
    showMessage("已取消加载");
  } else if (error?.name === "TimeoutError") {
    showMessage("服务响应超时，请稍后重试");
  } else {
    // 网络断开、解析失败和 HTTP 错误要走普通失败分支
    reportRequestFailure(error);
  }
}

要追踪“到底是谁先触发”，可以在创建来源时保存业务元数据，或在各自的事件入口记录日志；不要依赖合并信号猜测来源。特别是多个输入一开始就已经终止时，结果与输入顺序有关，不能用同一条提示覆盖所有场景。

四、清理自定义监听器并确认边界

fetch() 会处理它自己对信号的使用，但业务代码额外添加的 abort 监听器仍然由业务代码负责。只写 { once: true } 只能保证事件真正触发时自动移除；如果请求正常完成且没有任何来源终止，监听器仍可能留在长生命周期信号上。

async function requestWithLog(url, signal) {
  const onAbort = () => console.info("请求取消", signal.reason);
  signal.addEventListener("abort", onAbort, { once: true });

  try {
    const response = await fetch(url, { signal });
    // 等正文读取完，监听器的生命周期才覆盖完整操作
    return await response.text();
  } finally {
    // 成功、网络失败、用户取消都执行清理
    signal.removeEventListener("abort", onAbort);
  }
}

还要记住两个边界：调用合并信号的取消逻辑不会让输入控制器一起 aborted；而组合了 AbortSignal.timeout() 也不会把那个超时计时器变成可取消对象。如果业务必须提前确定性地停止计时器，可改用自己的 setTimeout() 与 clearTimeout()，再把控制器信号放进组合数组。

五、用四组场景完成反向验证

最后检查一次：每个请求是否创建了新的控制器；是否把合并信号真正传给了 fetch()；是否在读正文阶段继续使用同一取消链；是否保留了输入来源以解释原因；是否在 finally 中移除自己添加的监听器。满足这些条件时，AbortSignal.any() 就是在多个取消来源和一个请求入口之间建立清晰边界，而不是把取消逻辑隐藏起来。

相关问题

AbortSignal.any() 会取消其他输入信号吗？

不会。它只让返回的合并信号终止，用户控制器和超时信号仍各自遵守自己的生命周期。

为什么超时后有时看不到 TimeoutError？

如果另一个来源更早终止，合并信号会保留更早来源的 reason。应记录来源事件，不能只看最终提示猜测时间线。

请求成功后还要移除 abort 监听器吗？

如果监听器是业务代码添加的，要在 finally 中移除；一次性监听器只在事件触发时自动移除。