fetch 执行完，不等于业务请求成功

在 Node.js 项目里接入 AIGoCode，外层已经写了 try/catch，页面却仍然把一份错误 JSON 当成模型回复处理？先检查你有没有在 fetch 返回后判断 HTTP 状态。

本篇解决的是应用里的失败分支设计：区分没有拿到可用响应、拿到 HTTP 错误响应，以及响应体解析失败。它不替代状态码排错文章，也不逐项讲回复文字的字段路径。

先认清使用的是 SDK 还是 fetch

AIGoCode《第一次请求》的 Node.js 页签展示了不同调用入口。OpenAI Compatible 示例导入 openai 并创建客户端，通过 client.chat.completions.create 发出调用；Claude Messages 与 Gemini generateContent 示例则直接调用 fetch。

本文只讨论后两份 fetch 示例。不要把原始 fetch 的错误处理方式直接当成 OpenAI SDK 的错误约定；如果你的代码走的是 SDK，应按该依赖的实际返回和异常来处理。首先记录调用入口，才能找到应该增加判断的位置。

把收到响应后的判断写在明确位置

两份官方 fetch 示例在读取 result 后检查 response.ok：不成功时抛出由 result 序列化得到的错误，成功时才输出 result。这个显式分支很关键，因为 fetch 拿到 HTTP 响应后，单靠外层 catch 并不能替代状态检查。

对于自己的函数，可以把成功返回和失败返回约定清楚。例如成功路径交给后续的回复解析器，HTTP 失败路径则交给应用错误提示。这里是应用结构建议，不是 AIGoCode 新增了某种返回格式。

建议先保存可用的 response.status，再判断本次 HTTP 状态是否成功。即使错误对象能被转换成 JSON，也应留在失败路径，不要继续进入聊天气泡的渲染逻辑。不同阶段各有清楚的入口，比最后统一显示“没有内容”更容易排查。

还要给 JSON 解析失败留一个位置

官方示例按预期 JSON 响应编写，先调用 response.json，再检查 response.ok。把最小示例接进自己的业务函数时，还应考虑：如果这次响应体不能解析为 JSON，程序在哪里记录已经拿到的 HTTP 状态？

可以把记录状态、解析响应体、识别 HTTP 失败写成独立步骤。解析失败时保留“收到响应但未解析成功”这一结果，不要把它描述成“服务端没有任何响应”。同样，这也不足以单独证明是某个模型的问题；应以实际状态和响应类型继续核对。

本文没有测得 AIGoCode 会返回某种非 JSON 内容。上述情形是建议你的应用覆盖的边界测试，用来验证失败提示是否准确。

没有拿到响应时，别伪造 HTTP 状态码

如果 fetch 在拿到响应对象前就抛出异常，你还没有可供读取的这次 response.status。应用日志应记录发生在哪一步及脱敏后的异常信息，不要为了统一格式填成 401 或 500；这些数字会被误当成服务端的真实返回。

重试也应留在明确的业务策略中，不要给所有失败都包一个无条件循环。先判断是否已经收到结果、错误是否发生在解析或显示阶段，再决定下一步。本文不承诺重试次数、恢复时长或请求可安全重放。

用本地样本检查失败分支，不必每次都请求模型

可以用你自己的测试替身覆盖以下四种结果，观察程序是否进入对应分支。这些是人工构造的应用测试条件，不是平台保证会返回的内容：

返回成功 HTTP 状态及合法 JSON：进入成功处理函数。
返回失败 HTTP 状态及合法错误 JSON：保留实际状态，进入错误提示。
返回一个 HTTP 响应，但响应体解析失败：保留已有状态，标记解析失败。
请求阶段直接抛出异常：标记尚未取得响应，不填写虚构状态码。

日志可以保留协议名称、HTTP 状态（如果有）、失败阶段，以及少量脱敏错误信息。Gemini 的官方示例把 Key 放在查询参数中，记录请求地址时要遮蔽该参数值；也不要打印完整认证头或用户输入。

成功分支已经明确后，再去检查文字怎样读出来，可衔接本站API 有返回却不显示文字：三种响应结构怎么读。若已经拿到明确的服务端错误，再按401 与 403 的认证、额度排查处理。完成本次改动的判断标准，是每种失败都能给出符合实际阶段的提示，而不是所有异常都显示同一个空白回复。