Fetch 读取 response.json 后为何不能再次读取 body

写 Fetch 请求时，最容易误判的一点是：Response 看起来像一个可以反复取值的对象，但它里面的 body 实际上是一条只能消费一次的流。调用 await response.json() 后，再调用 response.text()、response.blob() 或第二次 response.json()，常见结果就是 TypeError，或者提示 body 已经被使用。

解决办法不是把同一个 Response 当缓存反复读取，而是先决定响应的唯一消费方式；只有确实需要两种视图时，才在第一次读取前调用 response.clone()。

Response body 为什么只能消费一次

Fetch 的响应体不是已经放在内存里的字符串，而是与 ReadableStream 关联的字节流。json() 会读取全部字节并解析成 JavaScript 值，text() 则读取同一来源并解码成字符串。第一个方法开始读取后，这条流就进入已扰动或已锁定的状态，第二个方法没有另一份数据可读。

调用完一次 response.json() 这类读取方法之后，响应体的流已经被消耗完毕，没有剩余内容可以第二次读取，所以后续再调用 response.json()、response.text() 这类方法都会抛出异常。

可以在排错时查看 bodyUsed，但要注意它是状态指示器，不是重置开关：

async function readOnce(response) {
  // 先记录状态，便于定位调用链中谁先消费了响应体。
  console.log("before:", response.bodyUsed);

  const data = await response.json();
  // json() 完成后，bodyUsed 变为 true；这里不能再调用 response.text()。
  console.log("after:", response.bodyUsed);
  return data;
}

因此，把 bodyUsed === false 写进重试循环并不能解决问题。它最多告诉你当前是否还有机会消费，不能让已消费的流重新出现。

普通接口应该采用一次解析、下游复用

如果接口约定返回 JSON，最稳妥的结构是让请求层只调用一次 json()，然后把解析后的对象交给状态处理、业务函数和错误判断。这样每个下游拿到的是普通对象，而不是共享的 Response 流。

async function requestUser(url) {
  const response = await fetch(url);
  // fetch 只在网络层失败时拒绝，HTTP 404/500 仍需显式判断。
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }

  // 响应体只消费一次，后续函数共享 data，不再触碰 response。
  const data = await response.json();
  return {
    data,
    isEmpty: data == null || data.items?.length === 0
  };
}

async function loadPage() {
  try {
    const result = await requestUser("/api/users");
    // 业务层读取普通对象，可以安全地重复访问字段。
    renderUsers(result.data.items ?? []);
  } catch (error) {
    // 解析失败和 HTTP 错误统一进入页面错误状态。
    showRequestError(error);
  }
}

这也是一种架构取舍：让“响应体消费”集中在边界层，把“业务对象复用”放在内部。不要为了打印调试日志，在业务函数里偷偷再次调用 response.text()。

需要原文和对象时怎么安排 clone

有些场景确实需要两份视图，例如解析 JSON 的同时保留原始文本用于开发环境日志，或者把响应交给两个相互独立的适配器。这时必须在任何消费发生之前克隆：

async function parseWithRawLog(url) {
  const response = await fetch(url);
  // 必须在 json() 之前复制，否则原始 body 已经无法再 clone。
  const rawResponse = response.clone();

  try {
    const data = await response.json();
    // 只有开发日志确实需要原文时，才消费克隆分支。
    const rawText = await rawResponse.text();
    debugLog({ status: response.status, rawText });
    return data;
  } catch (error) {
    // JSON 无法解析时仍可从克隆分支记录原文，便于定位接口返回的 HTML 或错误文本。
    const rawText = await rawResponse.text().catch(() => "");
    throw new Error(`响应解析失败：${rawText.slice(0, 200)}`);
  }
}

clone() 不是免费的缓存按钮。两条分支的消费速度不同，较慢的一侧可能积累尚未读取的数据；响应很大时，这会增加内存压力。文件下载、视频流或大 JSON 不适合为了日志而无条件 clone，更好的办法是让服务端提供可观测字段，或只在失败分支记录受限长度的信息。

用这张表判断该选哪种写法

排查重复消费时，可以沿着调用链问四个问题：谁拥有 Response？哪一个函数第一次调用了 body 方法？日志工具是否隐式读取了 body？是否把 Response 传给了两个互不知情的适配器？只要找到第一次消费点，后面的报错通常就能解释清楚。

相关问题

response.json() 调用两次一定会报错吗？

对同一个仍有 body 的 Response，第二次消费通常会因 body 已使用而拒绝。应缓存第一次得到的对象，而不是再次调用 json()。

bodyUsed 为 false 就能调用 clone 吗？

通常可以，但仍应让 clone 紧挨着 fetch 结果完成，并避免其他异步分支抢先消费 body。

能不能先 text() 再 JSON.parse？

可以，适合需要保留原文或诊断返回内容的场景；代价是要自行处理截断、编码和 JSON.parse 异常。

为什么 HTTP 500 不会自动进入 catch？

fetch() 的 Promise 主要在网络失败时拒绝，HTTP 状态仍是 Response。要先检查 response.ok 或状态码，再决定是否消费 body。