ReadableStream 取消后怎样释放请求

在前端读取大文件、长轮询响应或逐段生成的接口时，停止按钮看起来只是“不再把新内容写到页面”，但请求本身可能还在占用连接，响应体也可能仍然被消费。要把这件事收干净，需要先分清两个取消点：ReadableStreamDefaultReader.cancel() 结束当前消费端对流的兴趣，AbortController.abort() 把中止信号传给 fetch()，从而让请求和响应体消费一起结束。

官方资料：https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream

这篇只讨论 cancel 与 AbortSignal。目标是让一次流式请求具备清晰的停止边界：停止后不再继续读字节，底层请求收到中止信号，reader 的锁也能释放。

先分清两个取消点

我们先从对象关系看问题。Response.body 是一个 ReadableStream，调用 getReader() 后，流会被这个 reader 锁定。此时不能再从另一个地方拿第二个 reader，也不能直接对一个已经锁定的流调用 response.body.cancel()。

reader.cancel(reason) 表示“这个消费者不需要剩余数据了”。它会返回一个 Promise，并把原因交给底层源；已经排队但未读取的数据会被放弃。它解决的是流的消费端问题。

controller.abort(reason) 的范围更大：如果这个 signal 传给了 fetch()，它可以中止请求、响应体的消费和相关流操作。请求已经拿到响应头时再调用 abort()，后续读取响应体也可能以 AbortError 失败。

因此可以这样记：只想放弃剩余数据时，使用 reader 的 cancel()；要让网络请求也停止时，必须让 AbortSignal 进入 fetch()，并调用对应 controller 的 abort()。一个完整的停止动作通常会把两者放在同一个生命周期里。

让停止动作持有 AbortController

最容易出错的地方是把 controller 写成模块级单例，然后第二次请求继续复用它。controller 一旦 abort，关联的 signal 就保持已中止状态，后续请求拿到同一个 signal 时会立即失败。更稳妥的边界是“一次请求创建一个 controller”。

let activeRequest = null;

function createRequestSession() {
  // 每次请求都创建新的 controller，避免复用已经 aborted 的 signal。
  const controller = new AbortController();
  return { controller, reader: null };
}

function stopActiveRequest() {
  // 只取消当前会话；没有活动请求时按钮操作保持幂等。
  if (activeRequest && !activeRequest.controller.signal.aborted) {
    activeRequest.controller.abort("用户停止读取");
  }
}

停止按钮只需要调用 abort()，而不是强行从另一个事件处理器里重复获取 reader。这样无论请求还在等待响应头，还是已经进入响应体读取阶段，取消信号都沿着同一条请求链路传递。

读取响应流并处理取消异常

接下来把请求、reader 和异常处理放在同一个函数里。示例使用字节流和 TextDecoder，重点不在页面渲染，而在停止时的资源边界。代码中的接口地址是占位参数，真实项目应传入自己的请求地址。

async function readResponseStream(url, output) {
  const session = createRequestSession();
  activeRequest = session;
  const decoder = new TextDecoder();
  let completed = false;

  try {
    // 把同一个 signal 绑定到 fetch，让 abort 能影响请求和响应体。
    const response = await fetch(url, { signal: session.controller.signal });
    if (!response.ok) {
      throw new Error(`HTTP 请求失败：${response.status}`);
    }
    if (!response.body) {
      throw new Error("响应没有可读取的 body");
    }

    // getReader 会锁定 body，后续读取和清理都通过这个 reader 完成。
    session.reader = response.body.getReader();
    while (true) {
      const { done, value } = await session.reader.read();
      if (done) {
        completed = true;
        output.textContent += decoder.decode();
        break;
      }
      // 流式文本可能跨 chunk，decoder 会保留不完整的 UTF-8 字符。
      output.textContent += decoder.decode(value, { stream: true });
    }
  } catch (error) {
    // abort 可能发生在 fetch 阶段，也可能发生在 reader.read 阶段。
    if (session.controller.signal.aborted || error?.name === "AbortError") {
      output.textContent += "\n[已停止读取]";
      return;
    }
    throw error;
  } finally {
    if (session.reader) {
      if (!completed) {
        // 放弃尚未消费的字节；重复取消只作用于当前 reader。
        await session.reader.cancel("请求生命周期结束").catch(() => {});
      }
      // 释放 body 的锁，允许后续代码安全地判断或接管流。
      session.reader.releaseLock();
    }
    if (activeRequest === session) {
      activeRequest = null;
    }
  }
}

这里有三个关键判断。第一，response.ok 需要单独检查，因为 HTTP 404 或 500 并不一定让 fetch() 自身 reject。第二，取消可能在两个 await 点发生，所以要把 AbortError 和已中止的 signal 当作用户主动停止，而不是普通故障。第三，finally 无论正常结束、网络异常还是主动停止都会执行，清理代码不应只写在成功分支。

在 finally 中释放 reader 锁

getReader() 的实际影响不只是“拿到一个读取工具”，它还让 response.body.locked 进入锁定状态。reader.cancel() 负责通知流源不再需要剩余数据，reader.releaseLock() 负责解除 reader 对流的所有权。两者解决的是不同问题，不能把其中一个当成另一个的替代品。

如果请求已经正常读完，reader 通常已经收到 done: true，此时示例跳过再次 cancel，只做 releaseLock()。如果请求被中止或读取抛错，completed 仍然是 false，finally 会尝试取消剩余流，再释放锁。取消本身也返回 Promise，所以用 await 等它结束，并把清理阶段的次生异常压缩为可接受的结束路径。

复查三个容易失效的写法

只调用 reader.cancel()。这能结束当前流消费者，但如果请求的 controller 没有参与，应用层仍然没有一个明确的 fetch 中止信号。需要释放底层请求时，给 fetch 配置 signal 并调用 abort。

只调用 controller.abort() 却不处理 read() 的异常。abort 后正在等待的 read() 可能 reject。若把它当普通错误上报，用户每次点击停止都会看到错误提示；应该在 catch 中先判断 signal.aborted 或 error.name === "AbortError"。

在多个请求之间复用 controller 或 reader。controller 的 signal 不能在 abort 后复活，reader 也不能跨响应体复用。每次请求创建独立 session，并在 finally 清空活动引用，才能避免旧请求影响新请求。

总结

ReadableStream 的取消要分两层处理：reader.cancel() 放弃当前响应流的剩余数据，AbortController.abort() 把取消传递给 fetch 和响应体。实践中为每次请求创建独立 controller，使用 reader 读取，在 catch 中识别 AbortError，并在 finally 中按需 cancel 后 releaseLock，就能同时覆盖等待响应、读取中止、网络错误和正常完成。

相关问题

调用 response.body.cancel() 为什么报错？如果 body 已经被 getReader() 锁定，应该通过当前 reader.cancel() 操作；直接对锁定的流调用 cancel 可能抛出 TypeError。

正常读到 done 后还要 abort 吗？通常不需要。请求已经完成时 abort 没有待取消的工作，释放 reader 锁即可。

cancel 和 close 有什么区别？cancel 表示消费者不再需要流，剩余数据会丢弃；close 是底层源主动宣告后续没有更多数据，两者表达的生命周期含义不同。