JavaScript ReadableStream 怎样逐块处理响应

使用 fetch() 读取大文本、日志或服务端推送内容时，不必等整个响应下载完再调用 response.text()。更稳妥的做法是读取 response.body，让 ReadableStream 按块提供数据；二进制响应先经过 TextDecoderStream，再交给消费端。这样既能增量更新页面，也不会因为一个中文字符被拆在两个字节块里而解码乱码。

先把响应字节流变成可消费的文本流

浏览器的 Response.body 暴露的是 ReadableStream，默认读到的 chunk 通常是 Uint8Array。chunk 不是业务消息，也不保证按换行、JSON 或中文字符边界切分。因此，前端应该先确定“按字节处理”还是“按文本处理”。

如果接口返回 UTF-8 文本，推荐把字节流接入 TextDecoderStream。它会在流边界上保留不完整的多字节字符，输出字符串流。当前官方资料将 ReadableStream、Response.body 和 TextDecoderStream 都列为成熟的 Web API；具体浏览器范围仍应结合项目的支持矩阵确认。

一个可复用的读取函数可以这样组织：

async function readTextStream(url, { signal, onChunk }) {
  // 让 fetch 遵守外部取消信号，避免页面离开后请求继续占用资源
  const response = await fetch(url, { signal });
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }
  if (!response.body) {
    throw new Error("响应没有可读取的 body");
  }

  // 解码器负责处理跨 chunk 的 UTF-8 字节边界
  const textStream = response.body.pipeThrough(new TextDecoderStream());
  for await (const chunk of textStream) {
    // chunk 是字符串，但它仍不是完整业务消息，需按协议继续拆分
    onChunk(chunk);
  }
}

这里的 chunk 只代表当前可用的一段文本。如果服务端发送的是 NDJSON、SSE 或自定义分隔协议，应该把片段追加到缓冲区，按换行符或事件边界拆出完整记录，而不是把一次循环当成一条消息。

用 getReader 或异步迭代选择消费方式

for await...of 适合“收到一块就处理一块”的主流程，代码短，也能自然表达结束条件。需要精确控制读取、主动 releaseLock()，或者要兼容不支持流异步迭代的环境时，再使用 getReader()。

调用 getReader() 会给流加锁。锁存在期间，其他代码不能再次取得 reader；如果同时在两个地方消费同一个 response.body，常见结果就是 TypeError。因此，读取职责要集中到一个函数中，组件只接收已经整理好的文本片段。

async function readWithReader(response, onChunk) {
  // 默认 reader 每次返回 { value, done }，value 仍可能是字节数组
  const reader = response.body.getReader();
  const decoder = new TextDecoder();
  try {
    while (true) {
      const { value, done } = await reader.read();
      if (done) break;
      // stream: true 保留未完成的 UTF-8 字符，结束时再 flush
      onChunk(decoder.decode(value, { stream: true }));
    }
    // 把最后残留的解码状态输出出来，避免尾部字符丢失
    const tail = decoder.decode();
    if (tail) onChunk(tail);
  } finally {
    // 只在当前函数不再需要 reader 时释放流锁
    reader.releaseLock();
  }
}

这段写法和 TextDecoderStream 的职责相同，但手动维护了 decoder 状态。不要对每个 chunk 都写成 new TextDecoder().decode(value)；当一个汉字的 UTF-8 字节跨越两个 chunk 时，这种写法可能产生替换字符。

把取消、异常和流锁定放在同一条边界上

搜索框联想、聊天式输出或可关闭的长响应通常需要取消旧请求。创建一个 AbortController，把它的 signal 传给 fetch，按钮点击时调用 abort()。异常处理要把“用户主动取消”和“网络或协议失败”分开，否则日志里会充满无意义的错误。

const controller = new AbortController();

async function renderStream(url, output) {
  try {
    // 取消旧请求时，fetch 和 response.body 都会收到同一个 signal
    await readTextStream(url, {
      signal: controller.signal,
      onChunk(chunk) {
        // 真实项目可按帧批量更新 DOM，避免每个字节都触发重排
        output.textContent += chunk;
      },
    });
  } catch (error) {
    if (controller.signal.aborted) {
      // 主动取消是正常控制流，不要当成服务端故障上报
      return;
    }
    throw error;
  }
}

// 用户切换页面或查询词时调用，终止当前消费
function cancelCurrentRequest() {
  controller.abort();
}

生产代码里通常会为每次请求创建新的 controller，避免一个已经 abort 的 signal 被下一次请求复用。若直接使用 reader，还要在 finally 中决定是 releaseLock() 还是 cancel()：前者只释放读取权，后者表示不再关心剩余数据。选择哪一个取决于是否还要把同一条流交给其他消费者。

参数和边界速查

相关问题

为什么一次收到的 chunk 不是一行 JSON？

网络 chunk 属于传输层分片，不承诺业务边界。先累计字符串，再按换行、事件分隔符或协议长度字段解析。

ReadableStream 能不能直接调用 response.json？

可以，但 json() 会等待并读取完整 body；如果目标是逐块显示或降低等待时间，就应直接消费 response.body。

为什么第二次 getReader 会报错？

第一次 reader 仍锁着流。确认前一个消费者已经结束，并在适当位置调用 releaseLock()；如果流已被取消，则不能把它当成可继续读取的输入。

把“字节解码”“业务分帧”“界面更新”和“请求取消”拆成四个明确职责，ReadableStream 才不会变成难以排查的黑盒。小响应继续使用 text() 或 json() 更简单；只有需要增量体验、长响应或受控内存时，才值得引入这条流式路径。