AbortController 取消 fetch 后如何清理未消费的 response body

调用 fetch() 后，最容易混淆的是“请求已经取消”和“响应已经拿到但正文还没读完”。这两个阶段都可能看到 AbortError，但清理对象不同：前者应该调用 AbortController.abort()，后者如果只是放弃当前响应，还要处理 response.body 这个可读流。

先判断取消发生在请求还是 body 消费阶段

fetch(url) 的 Promise 在响应头到达后就可能完成，此时你已经拿到状态码和 headers，但正文通常仍由 Response.body 逐步提供。也就是说，下面两段代码处于不同阶段：

const response = await fetch(url, { signal });
// 这里拿到的是 Response，正文可能还没有被消费
const data = await response.json(); // 这里才开始/继续消费 body

如果取消发生在 fetch() 尚未完成之前，外层等待会被拒绝；如果响应已经返回，取消后再调用 text()、json() 或 reader 的 read()，读取动作同样可能以 AbortError 结束。不要用“有没有 Response”单独判断请求是否成功，body 是否读完是另一条生命周期。

用 AbortController 统一中止 fetch 和后续读取

用户点击取消、组件卸载或搜索词变化时，推荐让同一个 AbortSignal 贯穿请求和正文读取。这样无论取消发生在响应头之前还是正文读取期间，都能走同一条错误分支。

async function loadUser(signal) {
  try {
    // signal 把主动取消传给 fetch，也会影响后续 body 消费
    const response = await fetch("/api/user", { signal });

    if (!response.ok) {
      // HTTP 4xx/5xx 不是 fetch 网络异常，交给业务层处理
      throw new Error(`HTTP ${response.status}`);
    }

    // 这里可能在响应已返回后才因取消而拒绝
    return await response.json();
  } catch (error) {
    // 主动取消不应触发错误提示或盲目重试
    if (error?.name === "AbortError") return null;
    throw error;
  }
}

const controller = new AbortController();
loadUser(controller.signal);
// 取消按钮、路由切换或组件清理时调用
controller.abort();

这里的判断顺序很重要：先识别主动取消，再把真正的网络异常交给重试或错误提示；HTTP 状态码则要在 response.ok 上单独判断，因为它不会自动让 fetch() 抛异常。

Response 已返回但不再需要时取消 body

有些场景只需要 headers 或状态码，例如探测文件大小、检查缓存命中，拿到 Response 后就决定放弃正文。这时不要继续调用 text() 或 json()。如果 body 存在且仍可读，可以显式取消它：

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

  // 只需要 headers；不再消费正文时释放可读流
  if (response.body && !response.body.locked) {
    await response.body.cancel("正文不再需要");
  }

  return {
    status: response.status,
    contentType: response.headers.get("content-type"),
  };
}

cancel() 表示这个流后续的数据不再需要，返回一个 Promise，调用方应等待它完成。若已经通过 getReader() 锁定了 body，要先释放 reader，或由 reader 自己调用 cancel()；不能在流被锁定时直接把 response.body 当作普通对象再次取消。

区分 AbortError、网络错误和业务状态码

如果代码同时支持超时和用户取消，可以分别保留原因：超时控制器触发后记录“超时”，用户按钮触发后记录“主动取消”。无论采用一个 controller 还是组合 signal，最终都应让清理逻辑只执行一次，避免重复更新界面状态。

常见问题

调用 abort() 后还需要手动调用 response.body.cancel() 吗？

通常不需要重复取消同一条由该 signal 管理的读取链。若你是在拿到 Response 后主动放弃正文、没有用 controller 管理这条流，则可以直接对可读 body 调用 cancel()。

response.json() 抛 AbortError 是网络故障吗？

不一定。如果此前调用过关联 controller 的 abort()，它通常表示正文消费被主动中止。应先检查取消信号，再决定是否提示网络错误。

response.body 为空怎么办？

某些响应没有可消费的 body，先判断 response.body 是否存在；清理逻辑应允许空 body 正常结束，不要把它当成异常。

排查这类问题时，沿着“请求 Promise → Response 元数据 → body 流 → 业务状态码”逐层记录即可。这样既能释放未消费的响应，也不会把用户主动取消制造成一条误报。