JavaScript AbortSignal.any 怎么合并用户取消与超时：fetch 请求的竞态收口

一个搜索页同时遇到两种结束请求的原因：用户切换关键词，旧请求应该立刻停掉；接口迟迟没有响应，请求也不能无限占着加载状态。过去常见的写法是分别监听按钮和定时器，再在多个回调里清理状态，稍不留意就会让旧请求覆盖新结果。

AbortSignal.any() 可以把多个取消信号合成一个入口。把用户的 AbortController 和 AbortSignal.timeout() 交给它，再把返回值传给 fetch，请求只需要监听一次；结束时仍要读取异常名称，才能把“用户主动取消”和“超时”分开提示。

先把“取消”和“超时”看成同一条请求出口

以前的代码可能在按钮事件里调用 controller.abort()，又在 setTimeout 回调里调用另一套取消逻辑。它们最终都要让 fetch 停止，但清理加载状态、记录日志和恢复按钮的路径被拆散了。真正需要统一的是请求出口，而不是把所有原因都写成同一句提示。

MDN 对 AbortSignal.any() 的定义是：输入信号中任意一个终止，返回的信号就终止；如果多个信号几乎同时终止，返回信号保留先发生者的 reason。这正好对应“用户先取消”和“时间先耗尽”两种竞态。

用 AbortSignal.any 合并用户取消与时间上限

下面的例子把搜索请求限制在 8 秒内，同时允许用户点击取消。关键是每次发起新请求都创建新的 AbortController，不能把一个已经使用过的 signal 留给下一次请求。

let userCancelController;

async function search(keyword) {
  userCancelController?.abort();
  userCancelController = new AbortController();

  const timeoutSignal = AbortSignal.timeout(8_000);
  const combinedSignal = AbortSignal.any([
    userCancelController.signal,
    timeoutSignal
  ]);

  const response = await fetch(`/api/search?q=${encodeURIComponent(keyword)}`, {
    signal: combinedSignal
  });

  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }
  return response.json();
}

新关键词到来时先终止旧的 userCancelController，旧请求会沿着 combinedSignal 退出；新请求随后拿到一套全新的控制器和超时信号。不要在这里复用已经终止的 combinedSignal，因为合成信号一旦终止就不会恢复。

在 catch 里区分 AbortError 和 TimeoutError

合成信号只负责收口请求，不代表所有结束原因都应该显示同样的文案。用户切换关键词时，旧请求的 AbortError 通常不值得弹错误；超时则说明服务或网络没有在预期时间内完成，应该保留搜索框内容并给出重试入口。

async function runSearch(keyword, render) {
  try {
    const data = await search(keyword);
    render(data);
  } catch (error) {
    if (error.name === "AbortError") {
      return;
    }
    if (error.name === "TimeoutError") {
      render({ message: "请求超时，请重试" });
      return;
    }
    render({ message: "搜索失败，请稍后再试" });
  }
}

异常名称来自终止原因：AbortSignal.timeout() 触发时通常是 TimeoutError，控制器主动调用 abort() 则通常是 AbortError。如果项目封装层改写了异常，就应在封装层保留原因，而不是让页面只能根据一条模糊错误消息猜测。

竞态边界：旧请求退出不等于新结果可以随便写入

取消网络请求能减少无用工作，但不能把它当成所有竞态的唯一防线。某些响应已经进入 JavaScript 队列，或者底层服务已经完成处理，页面仍然要用请求序号或当前关键词校验结果是否属于最新操作。

let latestRequest = 0;

async function safeSearch(keyword, render) {
  const requestId = ++latestRequest;
  try {
    const data = await search(keyword);
    if (requestId !== latestRequest) {
      return;
    }
    render(data);
  } catch (error) {
    if (requestId !== latestRequest || error.name === "AbortError") {
      return;
    }
    render({ message: error.name === "TimeoutError" ? "请求超时，请重试" : "搜索失败" });
  }
}

这里的 requestId 是 UI 写入前的第二道检查。AbortSignal.any() 负责让旧请求尽快结束，requestId 负责阻止迟到结果修改当前界面，两者解决的是不同层次的问题。

兼容与验收要覆盖三个结束场景

AbortSignal.any() 属于较新的 Web API。MDN 将它标为 Baseline 2024，并提醒旧设备或旧浏览器可能不支持。上线前先做能力检测，目标环境不满足时可使用项目已经审核过的取消组合实现，不要直接执行不存在的方法。

function supportsCombinedAbort() {
  return typeof AbortSignal?.any === "function"
    && typeof AbortSignal?.timeout === "function";
}

if (!supportsCombinedAbort()) {
  // 使用项目已审核的兼容封装，保持相同的取消与超时语义。
}

验收时至少手动走三遍：点击取消，确认旧结果不再渲染；让请求超过 8 秒，确认页面显示超时提示；快速连续输入三个关键词，确认最后一个结果不会被前两个迟到响应覆盖。与此同时，服务端仍应把请求取消视为客户端行为，不能误认为业务操作一定没有发生。

常见问题

AbortSignal.any 会取消输入数组里的每个 signal 吗？

不会。它返回一个新的合成信号，输入信号中的任意一个终止时，合成信号跟着终止；输入控制器本身不会因为合成信号终止而被反向取消。

用户取消和超时同时发生时显示哪种提示？

合成信号保留第一个终止原因。页面可以按 error.name 或项目封装的原因字段处理，但不要依赖两个回调的执行先后猜测。

为什么每次搜索都要新建 AbortController？

控制器一旦调用过 abort() 就不可恢复。复用它会让下一次请求拿到已经终止的 signal，导致请求刚发起就结束。

AbortSignal.any 能解决所有接口竞态吗？

不能。它主要负责取消传播和时间上限；响应已经排队或服务端已经处理时，前端仍需用请求序号、业务版本或服务端幂等规则保护最终状态。

把多个结束原因收口，保留原因信息

这套写法的重点不是把代码压缩成一个 API 调用，而是让取消传播只有一个入口，同时让 UI 仍能区分用户动作、超时和真正的网络失败。先创建新的控制器，再用 AbortSignal.any() 合成，最后在 catch 和结果写入前各做一次判断，搜索、上传、预览等请求都可以沿用这个边界。