Fetch API 读取响应 JSON 失败时怎么保留原始文本

接口返回 502 页面、登录跳转 HTML 或被网关截断的半段 JSON 时，直接写 await response.json() 往往只得到一个解析异常，真正有用的原始响应已经没有机会再读。稳妥做法是：如果诊断原文比“自动解析”更重要，就先调用 text()，再对字符串执行 JSON.parse()；如果业务必须保留 json()，则在第一次消费 body 之前调用 response.clone()。

Response 的 body 默认只能消费一次。要保留 JSON 解析失败时的服务端原文，优先采用“先 text、后 JSON.parse”；需要同时走 json() 和 text() 时，必须提前 clone，并限制原文日志长度。

先判断 JSON 解析失败发生在哪里

fetch() 在收到 HTTP 响应头后就会得到 Response，即使状态码是 404 或 500，也不会因为 HTTP 错误自动 reject。先看 response.ok 和 response.status，再判断 body 是否真的是 JSON。Response.json() 既包含读取动作，也包含 JSON 解析动作；响应体无法解析时会抛出 SyntaxError，body 已锁定或已被消费时还可能是 TypeError。

用 text() 一次读取并保留原始响应

当接口格式不稳定、需要把错误原文写入诊断信息，或者前面经过网关时，推荐只消费一次 body。下面的函数把原文命名为 rawText，再用 JSON.parse() 得到 parsedData。这样无论解析成功还是失败，调用方都能拿到同一份原文。

async function readJsonWithRawText(url, init) {
  const response = await fetch(url, init);
  const rawText = await response.text(); // 先消费一次 body，保留诊断原文
  let parsedData = null;

  try {
    parsedData = JSON.parse(rawText); // 只解析字符串，不再读取 Response
  } catch (error) {
    return {
      ok: false,
      status: response.status,
      contentType: response.headers.get("content-type"),
      rawText,
      error
    }; // 解析失败仍返回原文，便于定位网关或服务端问题
  }

  return { ok: response.ok, status: response.status, parsedData, rawText };
}

这里的关键不是把 json() 换成另一种“更强”的解析器，而是明确 body 的所有权：text() 读完以后，后续逻辑只处理字符串。response.ok 仍要单独判断，因为合法 JSON 也可能来自 401 或 500。

需要两次读取时先 clone()

有些公共封装已经约定成功路径使用 json()，但错误路径又希望保留 text()。这时要在任何读取前复制 Response。原响应交给 json()，克隆出来的响应交给 text()；它们对应两个独立 body 分支。

async function readJsonAndKeepText(url) {
  const response = await fetch(url);
  const textResponse = response.clone(); // 必须在 json() 或 text() 之前克隆
  const rawTextPromise = textResponse.text();

  try {
    const parsedData = await response.json(); // 原响应承担 JSON 解析
    return { ok: response.ok, status: response.status, parsedData };
  } catch (error) {
    const rawText = await rawTextPromise; // 克隆分支保留失败时的原文
    return { ok: false, status: response.status, rawText, error };
  }
}

clone() 不是让同一个 body 无限重读。它创建的是新的 Response 分支；如果原响应已经被读取，再调用 clone() 会失败。对很大的响应也不要无条件克隆：较慢的分支可能积累未读数据，诊断接口更适合直接使用前面的“先 text、后 parse”策略。

把状态码、响应头和安全边界一起记下来

原始文本主要用于定位问题，不等于可以完整写入生产日志。建议至少记录 status、content-type、请求标识和截断后的 rawText；对可能含有令牌、Cookie、手机号或内部堆栈的内容先脱敏。浏览器的 text() 会把响应解码为字符串，接口返回的字符集与服务端声明不一致时，原文诊断也可能出现乱码，因此仍要核对响应头。

• 已知稳定且体积小的 JSON：直接使用 response.json()，并在外层捕获 SyntaxError。
• 需要稳定错误提示或排查网关：使用 response.text() 后再 JSON.parse()。
• 必须兼容既有 JSON 封装并保留原文：读取前 clone()，同时给日志设置长度上限。

处理完一次响应后，bodyUsed 可以帮助封装层发现重复读取。它只能说明 body 是否已消费，不能说明响应内容一定是 JSON；格式判断仍要结合 Content-Type、状态码和实际文本。

相关问题

为什么 catch 里再调用 response.text() 仍然失败？

因为 json() 在抛出解析异常前已经读取了 body。把读取顺序改为先 text()，或在第一次读取前准备 clone()。

看到 200 状态码就一定能调用 json() 吗？

不能。200 只代表 HTTP 状态成功，响应体仍可能是 HTML、空字符串或格式错误的 JSON。

clone() 会不会影响性能？

会有额外的读取和缓冲成本，尤其是大 body 或两个分支消费速度差异很大时。小型接口排错可以使用，下载流和大响应优先避免双读。

参考资料：MDN Response.json()、MDN Response.text()、MDN Response.clone()、MDN Response.bodyUsed。