硅基流动返回空内容，怎样区分无输出与解析遗漏

硅基流动返回成功却没有业务文本，先保留脱敏响应，再判断是服务没有提供最终文本，还是解析代码取错位置。成功状态只说明已观察到的 HTTP 状态未报错，不能证明响应体已完整接收或业务完成，也不能证明 answer 变量一定有值。下面四种响应均为本地合成样本，没有向真实平台付费调用。

从原始响应走到业务字段

把处理链划为四层：HTTP 状态与响应类型、JSON 顶层、choices 中的消息或增量、应用最终字段。每层记录自己看到的结构，别直接把所有空值变成空字符串。平台官方示例使用 choices[].message.content，并展示独立的 reasoning_content；后者不能未经业务设计就当作最终答案。

{"choices":[{"message":{"content":"合成答案"},"finish_reason":"stop"}]}
{"choices":[{"message":{"content":"","reasoning_content":"合成推理片段"},"finish_reason":"length"}]}
{"choices":[{"message":{"content":null,"tool_calls":[{"id":"demo","type":"function","function":{"name":"lookup","arguments":"{}"}}]},"finish_reason":"tool_calls"}]}
{"choices":[{"delta":{"content":"合成增量"},"finish_reason":null}]}

四行是四个独立对象，不能作为一个 JSON 文件整体解析。第一行代表正常非流式文本；第二行演示空最终文本和结束原因；第三行需要进入工具调用流程；第四行是流式分块的结构示意。它们用于测试解析分支，不承诺每个模型都返回全部字段或相同结束原因。

用断言替代静默兜底

解析器先判断本次是否请求流式，再区分 message 与 delta。检查 choices 是否存在、是不是数组以及是否为空；随后区分字段不存在、null、空字符串和只有空白。这些状态若都用 or "" 合并，后续就失去排查线索。

建议输出一个应用内部结果：state 取 text、tool_call、empty、unexpected_shape，另有 text、finish_reason 和 diagnostic_id。这些是本文设计的业务状态，不是平台返回码。工具调用交给既有执行与授权流程，不能把参数 JSON 当自然语言直接展示。

流式内容要累计到正确位置

流式场景要累计文本增量，忽略只含角色或结束信息的片段，记录是否收到应用期望的完成信号。只读第一块，可能只读到元数据；把每个分块都当完整答案，又会造成内容覆盖。中途异常时保存已接收长度与失败阶段，结果标为未完整，不应误报“模型返回空”。

日志仅记录结构摘要，如顶层键、选择数量、文本长度和结束原因。真实业务内容、推理片段和工具参数可能含敏感信息，不宜整份写入常规日志。需要复现时将结构与合成内容组合，保持导致解析失败的形态。

四种样本应该得到怎样的结果

正常文本应得到 text，空内容应得到明确 empty 且保留结束原因，工具调用应进入 tool_call，流式示意应由流式累计器处理。再补一个 choices: [] 的负例，确保不会出现数组越界异常。若原始响应有文字而业务字段为空，问题已被缩小到解析链；若响应本身没有最终文本，才继续核对模型支持、请求设置和结束状态。

还应测试只有空格或换行的最终内容。是否允许这类结果由业务定义，日志可以保留字符长度与空白分类，而不保存原文。

常见问题

把推理字段拼进答案就解决了吗？ 不一定，字段用途不同，还涉及内容展示与业务契约。

重试能修复取错字段吗？ 不能，稳定的解析错误通常需要修改代码。

成功状态能直接计为任务完成吗？ 应由解析和业务验证共同决定，工具调用或截断不能随意算完成。

继续处理相关问题

相关入口：硅基流动接入基础。

官方依据与核对日期

核对日：2026-10-23。硅基流动 Chat Completions：官方示例区分 message.content、reasoning_content 与结束信息；请求支持流式模式。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。