openapi-typescript项目中Response.body重复消费问题解析

在openapi-typescript项目的openapi-fetch模块中，开发者发现了一个关于错误响应处理的潜在问题。当API返回非JSON格式的错误响应时，现有的错误处理逻辑会导致TypeError异常，而不是正确返回错误文本内容。

问题背景

在HTTP请求中，服务器可能返回各种格式的错误响应。有些API设计会返回JSON格式的错误信息，而有些则可能返回纯文本或其他格式。openapi-fetch模块原本的设计意图是优先尝试将错误响应解析为JSON，如果失败则回退到文本格式。然而，这个处理流程存在一个关键缺陷。

技术细节分析

问题的核心在于Fetch API的Response对象特性。Response对象的body是一个只能被消费一次的流(stream)。原代码实现如下：

let error = {};
try {
  error = await response.json();
} catch {
  error = await response.text();
}

这段代码的问题在于：

1. 首先尝试调用response.json()
2. 如果JSON解析失败进入catch块
3. 然后尝试调用response.text()

但此时body已经被第一次的json()调用消费掉了，导致第二次调用text()时抛出"Body has already been consumed"错误。

解决方案

正确的处理方式应该是先以文本形式读取响应体，然后再尝试解析JSON：

const text = await response.text();
try {
  error = JSON.parse(text);
} catch {
  error = text;
}

这种实现方式：

1. 首先安全地将响应体完整读取为文本
2. 然后尝试将文本解析为JSON
3. 如果解析失败，直接使用原始文本

对开发者的影响

这个修复对于使用openapi-fetch的开发者来说非常重要，特别是在以下场景：

• 处理第三方API返回的非标准错误响应
• 服务器返回HTML错误页面而非JSON
• 网络代理或网关返回的纯文本错误信息

修复后，开发者能够可靠地获取任何格式的错误响应内容，而不是遇到意外的TypeError。

最佳实践建议

在处理HTTP响应时，开发者应当注意：

1. Response.body只能被消费一次，需要谨慎设计消费顺序
2. 对于可能包含多种内容类型的响应，应先以最通用的格式(如文本)读取
3. 错误处理时要考虑所有可能的响应格式，而不仅仅是预期的JSON

这个问题的修复体现了良好的错误处理设计原则，确保了代码在各种边缘情况下的健壮性。