Grok API返回格式异常：如何处理不完整的JSON字符串

当Grok API返回的JSON字符串被截断、缺少括号、引号未闭合或混入模型思考过程时，直接调用`json.Unmarshal`会触发panic或返回nil，轻则服务中断，重则数据丢失。这类问题在实际生产中并不少见，但完全可以通过一套系统化的修复流程来避免。 ## 识别并剥离非JSON前缀 第一步很简单：检查响应体开头是否包含自然语言前导文本，比如“让我思考一下……”“好的，这是结果：”之类的模型思考痕迹。它们不属于JSON正文，必须提前剔除。 第二步，用正则`/(?s)({.*})/`提取第一个完整JSON对象——这里的关键是启用`s`标志，让`.`能够匹配换行符，否则跨行结构会漏掉。如果正则没有命中，则回退到扫描首个`{`和最后一个`}`之间的子串。但有个硬性前提：**必须验证这个子串是否以`{`开头、以`}`结尾**，否则截取到的可能是个残缺对象。 ## 修复常见语法破损 拿到候选JSON后，接下来处理最常见的三类语法问题。 **方法一：补全缺失的右括号或右方括号** 统计字符串中`{`与`}`、`[`与`]`的数量差值。如果`{`比`}`多1个，就在末尾追加一个`}`；如果`[`多1个，则追加`]`。注意：不能盲目补多个，补错一个只会让整个结构更烂。 **方法二：修复未闭合的字符串** 从最后一个未配对的引号位置开始，向后查找下一个双引号。如果找不到，就在字符串末尾补上`"`。同时要跳过转义引号`"`，否则会误判闭合状态。 **方法三：删除尾部非法逗号** 用正则匹配`, s* }$`或`, s* ]$`，替换为空字符串。JSON标准不允许数组或对象末尾出现逗号，Go的`json.Unmarshal`对此极其严格，一点商量余地都没有。 ## 用容错解析器替代原生Unmarshal 手动修复总有遗漏，此时可以引入社区方案——`github.com/adhocore/json-fixer`。它能在输入严重破损时仍返回可用结构体。只需调用`fixed, err := jsonfixer.Fix(string(rawBytes))`，得到修复后的字节切片，然后用标准`json.Unmarshal(fixed, &v)`解析即可。 该库默认启用智能修复模式，会处理键无引号、布尔值小写`true`/`false`、数字前导零等非标准但常见的情况。不过有一点要特别注意：**不要跳过err检查**——即使修复成功，也可能因字段类型冲突返回warning级错误，此时应记录日志但继续解析，而不是中断流程。 ## 构建防御性解码流程 有了前面的技术，可以拼装成一个完整的防御链条： 1. 接收原始响应体`body`，先做UTF-8编码校验，丢弃含BOM或非法字节的响应。 2. 调用剥离前缀函数，获取候选JSON字符串`candidate`。 3. 如果`candidate`长度小于10，直接返回错误——极短字符串几乎不可能是有效JSON，没必要浪费后续修复。 4. 尝试用`json-fixer`修复并解析；如果仍失败，降级为逐字段手动提取：利用`json.RawMessage`延迟解析关键字段，避开破损区域。 5. 对所有解析出的字段做空值校验，特别是ID、timestamp这类不可为空的字段。缺失时填充默认值或打标记，供下游逻辑判断。 这套流程跑下来，大多数Grok API的返回异常都能被平滑消化。一句总结：先剥离前缀、再语法修复、配合容错解析、最后兜底提取——每一步都加一道保险，服务稳定性自然就上去了。