Fetch流式读取ReadableStream响应

Fetch流式读取的入口是response.body：取得ReadableStream的reader，循环等待reader.read()，按done判断结束。对于UTF-8文本，还要用同一个TextDecoder跨块解码；一个字节块不保证对应一个完整字符，更不保证是一条JSON消息。

Fetch规范：https://fetch.spec.whatwg.org/

目标与协议边界

本文目标是浏览器逐段消费UTF-8纯文本响应，提供HTTP状态判断、严格解码、顺序回调及取消清理。它不是SSE解析器，也不是NDJSON解析器。若服务器发送这些协议，文本解码之后还需增加记录边界解析。

约定接口属于同源，或者已经正确配置CORS；服务器、反向代理和中间层允许及时传递数据。只有客户端改成read循环，无法强迫上游停止缓冲。下面是原创浏览器JavaScript示例，没有声称已经对真实服务器执行。

理解响应流与读取器

Response是响应对象，body是正文流或null。默认reader读取时得到的value是Uint8Array字节块；TextDecoder负责解码，onText负责消费文本，三者各有职责。

一个reader会锁定该流，不能同时再用另一个读取器消费它。也不要先调用response.text()读取完毕，再尝试使用同一正文做流式读取。完整读取和逐块消费是两种不同选择。

实现逐块UTF8文本读取

async function readUtf8Response(url, { signal, onText }) {
  // 回调约定为接收文本片段，可同步返回，也可返回Promise。
  if (typeof onText !== "function") throw new TypeError("需要onText回调");
  const response = await fetch(url, { signal });
  if (!response.ok) {
    // 放弃错误响应的正文，清理失败不覆盖HTTP错误。
    try { await response.body?.cancel(); } catch {}
    throw new Error(`HTTP ${response.status}`);
  }
  if (!response.body) throw new Error("响应没有可读正文");

  const reader = response.body.getReader();
  const decoder = new TextDecoder("utf-8", { fatal: true });
  let completed = false;
  try {
    for (;;) {
      const { done, value } = await reader.read();
      if (done) break;
      // 跨块保存不完整字符，不能对每个字节块独立解码。
      const text = decoder.decode(value, { stream: true });
      if (text) await onText(text);
    }
    // 正常结束时刷新残留字节；不完整的UTF-8会在严格模式下报错。
    const tail = decoder.decode();
    if (tail) await onText(tail);
    completed = true;
  } finally {
    try {
      if (!completed) {
        // 业务回调或读取失败后放弃消费，不让清理错误掩盖原错误。
        try { await reader.cancel(); } catch {}
      }
    } finally {
      reader.releaseLock();
    }
  }
}

stream: true让解码器保留跨块字符状态。正常结束后，不传输入再调用一次decode完成刷新。本文选择fatal: true，遇到非法UTF-8就失败，避免把损坏文本当成正确业务内容；如果产品确实允许替换字符，应显式调整规则。

循环等待onText，有助于保持应用层消费顺序，避免无限创建尚未完成的异步回调。这并不意味着网络全链路没有缓冲，也不能自动防止回调把所有文本追加进一个无限增长的数组。

completed只在正常解码和消费结束后设置。读取错误、解码错误或回调错误都会进入清理路径，原错误继续传播。流已错误时cancel也可能拒绝，示例仅忽略清理阶段的拒绝，不吞掉主要业务错误。

连接调用方与取消控制

function startTextRequest(url, onText) {
  const controller = new AbortController();
  const finished = readUtf8Response(url, {
    signal: controller.signal,
    onText,
  });
  return {
    finished,
    // 页面停止按钮或卸载清理逻辑调用此方法，不要仅修改一个循环标志。
    stop: () => controller.abort(),
    signal: controller.signal,
  };
}

// 此相对地址须由自己的服务器提供UTF-8流式文本，不是现成公共接口。
const job = startTextRequest("/api/text-stream", text => {
  console.log(text); // 演示逐段消费；生产端应限制渲染和保留的数据量。
});
job.finished.catch(error => {
  if (job.signal.aborted) {
    console.info("请求已取消");
  } else {
    console.error("读取失败", error);
  }
});
// 需要停止时，由实际事件处理器调用job.stop()。

AbortController通过signal传给fetch。页面停止按钮、切换请求或组件卸载时调用stop，由同一次请求持有自己的controller。这里的/api/text-stream需要你自己提供，响应内容也必须符合前面的UTF-8约定。

releaseLock只解除读取器锁，不代表取消网络请求。示例在未完成消费时先尝试cancel，再释放锁。controller取消也不会强行终止一个用户自定义的异步onText；若回调可能长期等待，它需要自己的取消与超时设计。

示例用signal是否已取消来区分用户停止与其他错误，避免只依赖某种错误名称。页面若把文字呈现为内容，应使用文本方式写入合适节点，不要把服务器文本直接当作HTML。

处理常见误区

HTTP 404、500仍可能得到Response，不能只用fetch的Promise是否拒绝判断成功。本文先检查ok，错误响应不进入正常文本消费。对于无正文的成功响应，示例明确报错；若业务允许204等空结果，可在该分支定义单独的成功返回。

分块大小取决于传输与实现，不能以每次read当作一行、一个token或一条事件。NDJSON需要保留不完整行，SSE需要依据自身事件格式处理；单纯的JSON.parse(value)既把字节误当文本，又忽略跨块记录。

若文字直到最后才一起出现，先区分服务器输出、代理缓冲、内容编码与前端渲染批次。不要仅凭客户端存在reader就断言上游已经流式发送，也不要承诺每次服务端写入都会对应一次浏览器回调。

速查与相关问题

为什么中文出现替换字符或解码错误？

先核对实际编码，然后检查是否把每块独立解码、是否遗漏末尾刷新。严格UTF-8模式会让非法或结尾不完整的编码明确失败。

流式读取一定减少内存吗？

只有业务也逐段处理、限制缓存时才有这种可能。读取后仍把所有内容保存到字符串、列表或页面节点，内存仍会随总内容增长。

还需要TextDecoderStream吗？

它是另一种管道式组织方式。本文手动解码便于展示状态与清理责任；项目选择时还应核对目标浏览器能力，不必在同一正文上叠加两套读取器。

Streams规范：https://streams.spec.whatwg.org/

Encoding规范：https://encoding.spec.whatwg.org/