前端 ReadableStream 读取中断后怎么取消底层请求

前端用 ReadableStream 逐块显示大响应时，点击“停止”不能只把读取循环 break 掉。break 只代表当前消费者不再处理后续分块，真正要取消 fetch 的底层请求，应把同一个 AbortSignal 传给 fetch，再由 AbortController.abort() 发出取消信号。读取器负责消费和解锁，控制器负责取消请求，两者要配合使用。

最小可靠方案是：fetch(url, { signal })、response.body.getReader()、循环 read()，停止时调用 controller.abort()，在 finally 中释放 reader 锁；不要把 reader.cancel() 当作所有网络请求的替代品。

把取消信号传到 fetch 和 ReadableStream

先准备一个可复用的读取函数。response.body 可能为空，因此生产代码应先做空值判断；拿到 reader 后，流会被锁定给当前读取器，其他消费者不能同时读取。

async function readResponse(url, onText, signal) {
  // signal 必须传给 fetch，停止时才能影响底层请求
  const response = await fetch(url, { signal });
  if (!response.body) {
    throw new Error("当前响应没有可读取的 body");
  }

  const reader = response.body.getReader();
  const decoder = new TextDecoder("utf-8");
  try {
    while (true) {
      // 没有新分块时，read 会等待；这不是忙等循环
      const { done, value } = await reader.read();
      if (done) break;
      onText(decoder.decode(value, { stream: true }));
    }
    // 把 decoder 内部暂存的最后半个字符冲出来
    const tail = decoder.decode();
    if (tail) onText(tail);
  } finally {
    // 释放流锁，让后续逻辑可以重新接管这个 stream
    reader.releaseLock();
  }
}

停止按钮应持有同一个控制器。这里的关键不是给读取循环增加一个布尔变量，而是把 signal 送进发起请求的那一层：

const controller = new AbortController();

stopButton.addEventListener("click", () => {
  // abort 会让 fetch 和正在等待的读取感知取消
  controller.abort("用户主动停止");
});

readResponse("/api/report", renderText, controller.signal)
  .catch((error) => {
    // 主动停止是已处理状态，不应显示成系统故障
    if (error.name === "AbortError") return;
    showError(error);
  });

逐块解码时不要把取消当成普通结束

read() 返回的结果只有三种核心状态：有分块时是 done: false，正常关闭时是 done: true，流出错时 Promise 被拒绝。取消请求通常会以异常路径离开循环，所以不要把所有退出都记录成“下载完成”。

如果直接把每个 Uint8Array 转成字符串，跨分块的 UTF-8 字符可能被拆开。TextDecoder.decode(value, { stream: true }) 会保留未完成的字节，正常结束时再调用一次不带参数的 decode() 完成收尾。

这也是背压边界：只有在上一块处理完成后才再次调用 read()。如果 onText 还要做昂贵的 DOM 更新，应把文本先放入缓冲区，合并到下一帧渲染，避免每个网络分块都触发一次布局。

reader.cancel()、abort() 和 releaseLock() 怎么选

三者作用不同。controller.abort() 面向请求，适合取消由 fetch 发起的网络操作；reader.cancel() 面向流消费者，表示不再需要这个流，底层 source 有机会执行自己的 cancel 回调；reader.releaseLock() 只释放读取器对流的锁，本身不会取消请求，也不会清空已经到达的数据。

因此，用户主动停止时优先调用 abort()；如果是自定义 ReadableStream，还要在它的 cancel() 回调中关闭定时器、文件句柄或其他数据源。不要在一个仍有未完成 read() 的 reader 上随意创建第二个 reader，也不要在 finally 中用 releaseLock() 假装完成取消。

可以把收尾检查写成一张小清单：请求创建时保存 controller；读取时只让一个 reader 持有锁；停止时调用 abort；异常处理识别 AbortError；正常 done 时冲刷 decoder；最终释放锁并停止界面更新。

常见问题

只写 break 能不能停止 fetch？

不能把它当成可靠的网络取消。它只结束当前消费循环，底层请求仍应通过传给 fetch 的 AbortSignal 取消。

调用 abort 后为什么还看到最后一小段文字？

取消发生在分块交付或渲染之间时，已经取到的字节仍可能进入当前回调。渲染前检查 signal.aborted，并让停止状态阻止后续 UI 更新。

什么时候需要 reader.cancel()？

当消费者明确放弃一个流，尤其是自定义流需要触发底层 source 的清理回调时使用；对 fetch 请求的主动中止仍应保留 AbortController。