AbortController 复用后请求立即取消的生命周期

如果一个页面把 AbortController 保存起来反复用于搜索请求，第一次调用 abort() 之后，后面的请求很可能在发出时就立即取消。原因不是 fetch 随机失败，而是它接收到的 AbortSignal 已经进入不可逆的 aborted 状态。

生产环境的处理原则很简单：旧请求由旧控制器负责取消，新请求必须创建新的控制器；同时把取消异常与真正的网络错误分开记录。这样既能避免请求竞争，也不会让正常的用户输入切换被错误地记成系统故障。

先把生产目标定清楚

这类问题通常出现在搜索框、筛选器、联想下拉或详情切换：用户连续输入关键词，代码希望取消上一次请求，只保留最新一次。需要保证三件事：

• 旧请求可以被取消，减少无效响应和带宽消耗；
• 新请求使用未取消的信号，不会刚创建就失败；
• 旧响应即使晚到，也不能覆盖最新结果。

AbortController 为什么不能复用

AbortController 本身提供 abort()，真正传给 fetch 的是它的 signal。调用 abort() 后，signal 会保持已取消状态；它没有“重新启用”或“重置”方法。

可以用下面的最小示例观察这个生命周期。代码中的第二次请求故意继续使用第一次请求的 signal，重点不是接口地址，而是信号对象的状态。

const controller = new AbortController();

// 第一次请求使用尚未取消的信号。
fetch('/api/suggestions?q=go', { signal: controller.signal })
  .catch((error) => {
    // 用户主动取消属于预期分支，不要当成系统故障。
    if (error.name !== 'AbortError') {
      console.error('第一次请求失败', error);
    }
  });

// 取消之后，signal.aborted 会变成 true，并且不会恢复。
controller.abort();
console.log(controller.signal.aborted); // true

// 复用已经取消的 signal，新请求会很快进入取消分支。
fetch('/api/suggestions?q=golang', { signal: controller.signal })
  .catch((error) => {
    // 这里通常会得到 AbortError，而不是一次全新的请求。
    console.log(error.name);
  });

排查时先看 signal.aborted，再看请求错误名称。只要在调用 fetch 前它已经是 true，继续调整超时、重试或后端接口都解决不了“立即取消”这个根因。

请求切换时每次新建控制器

把控制器放在“当前请求”这一层，而不是把一个实例当成全局常量。新请求开始前先取消旧控制器，然后立刻创建新的控制器，并把新的 signal 传给新的 fetch。

let activeController = null;

async function searchSuggestions(keyword) {
  // 新请求开始前，只取消仍由当前页面维护的旧请求。
  activeController?.abort();

  // 每次请求都创建新的控制器，避免继承已取消的 signal。
  const controller = new AbortController();
  activeController = controller;

  try {
    const response = await fetch(`/api/suggestions?q=${encodeURIComponent(keyword)}`, {
      // 当前请求只绑定自己的信号。
      signal: controller.signal,
      headers: { Accept: 'application/json' },
    });

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

    return await response.json();
  } catch (error) {
    // AbortError 表示用户已经触发了请求切换，不必弹出失败提示。
    if (error.name === 'AbortError') {
      return null;
    }
    throw error;
  } finally {
    // 只有自己仍是当前控制器时才清空引用，避免误删新请求的控制器。
    if (activeController === controller) {
      activeController = null;
    }
  }
}

这里的 finally 判断很重要。请求 A 结束时，当前引用可能已经指向请求 B；如果无条件把全局引用设为 null，后续代码就失去了取消请求 B 的能力。

再挡住旧响应覆盖新结果

取消请求能够减少旧响应到达的机会，但业务代码最好仍然保留“只接受最后一次请求”的判断。因为请求可能已经完成、进入解析阶段，或者使用的封装层没有完全遵循取消信号。

let latestRequestId = 0;

async function loadList(keyword, render) {
  // 自增编号用来识别当前输入对应的最后一次请求。
  const requestId = ++latestRequestId;
  const data = await searchSuggestions(keyword);

  // 取消分支返回 null；旧请求即使完成，也不能覆盖新结果。
  if (data === null || requestId !== latestRequestId) {
    return;
  }

  // 只有最新请求才允许更新界面。
  render(data);
}

如果项目已经使用框架的请求库，也可以使用库提供的取消机制，但判断原则不变：取消对象不能跨请求复活，响应写入必须绑定当前请求身份。

日志与发布前检查

不要把主动取消和网络故障混在一个错误指标里。日志至少可以带上请求用途、请求编号、是否已取消和错误名称；用户主动输入导致的取消通常只需要调试级别，真正的 HTTP 错误和解析失败再进入告警统计。

function logRequestError(error, context) {
  // 主动取消是正常控制流，避免制造误报。
  if (error?.name === 'AbortError') {
    console.debug('请求已按页面状态取消', context);
    return;
  }

  // 其他错误保留上下文，便于按接口和请求编号定位。
  console.error('请求异常', {
    ...context,
    errorName: error?.name,
    message: error?.message,
  });
}

上线前可以按下面的清单检查实现：

常见问题

AbortController 可以在 abort 后 reset 吗？

不能。应创建新的 AbortController，并把新的 signal 传给下一次请求。

为什么新请求没有真正发到服务器？

如果传入的 signal 已经是 aborted，fetch 会在请求处理早期拒绝。先检查控制器的创建时机和 signal.aborted，不要只看服务端访问日志。

只调用 abort，不做请求编号判断够吗？

不一定。请求可能已完成或进入后续解析逻辑，编号判断是最后一道写入保护，尤其适合搜索和快速切换场景。

记住一句话：AbortController 是一次性取消开关，不是可以反复复位的请求容器。取消旧请求和创建新请求必须是两个连续但独立的动作，再用当前请求身份保护结果写入，才能把“立即取消”和“旧结果串台”同时处理掉。