AbortController 取消 fetch 后如何避免读取响应体报错

AbortController 取消 fetch 后，最容易误判的一点是：fetch() 已经返回了 Response，并不等于响应体已经读完。如果取消发生在响应头到达、response.json() 或 response.text() 之前，后续读取仍可能抛出 AbortError。处理方式是把取消当作正常的控制分支，在读取响应体前检查信号，并保证一个 Response 只消费一次。

拿到 Response 后不要无条件读取 body：先判断 signal.aborted，再检查 response.ok，最后只调用一次 json 或 text；catch 中单独吞掉 AbortError，其他错误继续交给错误状态。

取消信号为什么会影响响应体读取

浏览器收到状态码和响应头后，fetch() 的 Promise 就可能兑现，此时得到的是 Response 外壳，body 仍在流式到达。若这时调用 controller.abort()，取消不仅影响网络请求，也会影响响应体消费。于是下面这种写法存在明确的失败窗口：

const controller = new AbortController();
const response = await fetch('/api/search', { signal: controller.signal });
controller.abort();

// 取消发生在 body 尚未读取时，这里可能抛出 AbortError
const data = await response.json();

这不是服务器返回的业务错误，而是本地读取被取消。MDN 对 AbortController 的说明也明确区分了“fetch 已兑现”和“响应体尚未读取”的情况。可以参考 AbortController 文档 与 Fetch API 的取消说明。

先判断取消，再决定是否读取响应体

最小修复不是把所有异常都忽略，而是在进入 body reader 前增加一次信号判断，并把取消异常单独处理：

async function readJson(url, signal) {
  try {
    const response = await fetch(url, { signal });

    // fetch 返回 Response 后，先阻止已经取消的读取
    if (signal.aborted) {
      return { state: 'cancelled' };
    }

    // fetch 遇到 404/500 仍可能兑现，必须单独检查 HTTP 状态
    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    // 一个 Response body 只消费一次
    return { state: 'success', data: await response.json() };
  } catch (error) {
    // 用户主动取消不应显示成红色网络错误
    if (error.name === 'AbortError') {
      return { state: 'cancelled' };
    }
    throw error;
  }
}

这里的顺序有实际意义：signal.aborted 处理取消竞态，response.ok 处理 HTTP 状态，json() 只负责消费并解析 body。若接口返回文本，把最后一行替换为 await response.text() 即可，不要先读 text 再读 json。

用请求序号避免旧响应覆盖新结果

取消只能通知浏览器停止后续工作，不能替代界面层的竞态保护。用户连续输入关键词时，建议保存当前 controller，并给每轮请求一个序号：

let activeController = null;
let requestId = 0;

async function search(keyword, render) {
  activeController?.abort();
  const controller = new AbortController();
  activeController = controller;
  const currentId = ++requestId;

  try {
    const result = await readJson(`/api/search?q=${encodeURIComponent(keyword)}`, controller.signal);

    // 旧响应即使侥幸回来，也不能覆盖当前输入
    if (currentId !== requestId || result.state === 'cancelled') return;
    render(result.data);
  } catch (error) {
    if (currentId === requestId) render({ error: error.message });
  } finally {
    // 只清理仍属于当前请求的引用
    if (activeController === controller) activeController = null;
  }
}

组件卸载时也应调用当前 controller 的 abort()，并让取消分支静默结束。这样既减少无用的 body 读取，也避免卸载后的异步回调更新已不存在的界面。

常见问题

AbortController 会让服务器端任务自动停止吗？

不一定。它主要控制浏览器侧的请求和 body 消费；服务器是否停止处理，要看服务端是否也支持取消信号或连接断开语义。

为什么第二次调用 response.json() 会报错？

响应体是流，第一次读取后就可能被标记为 disturbed；如果已经通过 reader 锁定，也会处于 locked 状态。需要多次读取时，必须在第一次消费前调用 response.clone()。

所有 catch 都判断 AbortError 就够了吗？

不够。解析失败、CORS 或网络断开都可能是其他异常；只把明确的 AbortError 当作取消，其余错误保留给重试、提示或监控逻辑。

实际项目可以把“取消、HTTP 状态、解析、竞态”分别映射为页面状态。这样取消搜索时安静收尾，接口异常时保留诊断信息，新的请求也不会被旧结果覆盖。