AI 流式输出如何避免半截 JSON:Go 逐块解析与字段完整性检查
来源:17golang原创
时间:2026-08-29 23:56:17 395浏览 收藏
AI 接口改成流式返回后,最容易出现的不是网络断开,而是把每个数据块都当成完整 JSON 去解码。一个对象可能被拆在两个 chunk 中,第一块只有半个字符串,第二块才补上结束引号;此时逐块调用 json.Unmarshal,得到的只是“输入未完整”,不是业务字段真的缺失。
- chunk 只是传输分片,不等于一个完整 JSON 值,解析前要先进入 buffer。
- 缓冲区应在成功 decode 后按消费位置前移,不能每次失败都丢弃全部内容。
- required 字段检查必须放在对象边界确认之后,避免把半截对象误判为缺字段。
- 流结束时仍有残留字节,应进入明确的 incomplete 状态,而不是静默返回空答案。
半截 JSON 的问题现场:chunk 并不等于对象
假设上游把一个工具结果分成两个块:第一块是 {"answer":"Go 流式,第二块才是 输出","done":true}。网络层认为这两块都已成功到达,但 JSON 层只能在第二块拼入后才看到完整字符串。
chunks := []string{
`{"answer":"Go 流式`,
`输出","done":true}`,
}
for _, chunk := range chunks {
var item map[string]any
if err := json.Unmarshal([]byte(chunk), &item); err != nil {
fmt.Println(err)
}
}
第一轮报错并不说明响应格式错了。真正的问题是 chunk 还没有形成完整值,直接交给 json.Unmarshal 会把传输边界误当成语法边界。

最小修复:把分片先放进 buffer
修复思路很小:每次收到 chunk 就追加到 buffer,然后尝试从缓冲区读取一个完整 JSON 值。读取失败时保留原内容,继续等待下一个 chunk;读取成功后才删除已经消费的字节。
type StreamItem struct {
Answer string `json:"answer"`
Done bool `json:"done"`
}
func decodeStream(chunks []string) ([]StreamItem, error) {
var buffer bytes.Buffer
var items []StreamItem
for _, chunk := range chunks {
buffer.WriteString(chunk)
decoder := json.NewDecoder(&buffer)
for buffer.Len() > 0 {
var item StreamItem
if err := decoder.Decode(&item); err != nil {
if errors.Is(err, io.EOF) {
break
}
return nil, err
}
items = append(items, item)
}
}
return items, nil
}
示例的重点是“失败时不丢缓冲区”。生产实现还需要记录消费位置,避免重复创建解码器时把已消费内容再次送入解析器;如果协议是一行一个 JSON,则可以先按换行边界切分,再对完整行调用 json.Unmarshal,边界会更容易审计。
字段完整性检查要等到 done 之后
流式对象解析成功,只能说明 JSON 语法完整,不代表 AI 结果满足业务合同。每个 event 先进入 decode,比如 answer 是必填字段,done 表示上游已经结束;二者的判断顺序应清晰地写在代码里。
func validate(item StreamItem) error {
if item.Answer == "" {
return errors.New("required field answer is empty")
}
if !item.Done {
return nil
}
return nil
}
不要在每个网络块到达时就把当前对象写入最终答案。只有 decode 成功、required 字段通过,并且收到 done 事件,才把状态置为完成。若流在中间断开,则保存已收到的片段并返回可重试的 incomplete,而不是伪造完整回答。

结束事件、残留字节和重复消费
最后一块数据到达并不自动保证缓冲区为空。可以把 done 当作协议层结束信号,再检查是否存在无法解码的残留字节。残留内容可能是截断的 JSON,也可能是协议分隔符没有清理。
| 状态 | 判断 | 处理 |
|---|---|---|
| 继续接收 | decode 未完成且未收到 done | 保留 buffer,等待下一块 |
| 正常完成 | decode 成功、required 通过、收到 done | 提交答案并记录 request_id |
| 不完整 | 收到 done 但 buffer 仍有残留 | 标记 incomplete,不当作成功 |
| 格式错误 | 已确认边界仍无法解析 | 记录原始片段摘要并停止 |
用四组输入复查解析器
- 把完整 JSON 放进一个 chunk,确认一次 decode 即可得到
done=true。 - 把字符串、转义符和 Unicode 字符分别切在两个 chunk 之间,确认 buffer 能等待拼接。
- 在收到半截对象后直接结束流,确认返回 incomplete 而不是空对象。
- 追加一个缺少
answer的完整对象,确认 required 检查失败且不会进入完成状态。
测试日志至少打印 chunk 序号、buffer 剩余长度、decode 结果和最终状态。不要打印用户原文或密钥样文本;需要排查时记录长度、哈希或脱敏后的字段即可。
相关问题
为什么不用每个 chunk 都调用 json.Unmarshal?
因为传输分片没有 JSON 语义。一个字符串、数组或对象都可能跨越多个 chunk,逐块解码会把正常的半截输入误判为格式错误。
json.Decoder 遇到半截输入会不会丢数据?
只要底层读取源和缓冲区没有被错误重置,遇到未完成值时应继续保留输入。实现中要明确消费位置,避免重新绑定 reader 后重复读取或丢掉未消费字节。
收到 done 就一定能提交答案吗?
不一定。还要确认最后一个对象已完整 decode、必填字段通过,并且缓冲区没有残留的截断内容。
把“流结束”与“结果可用”分开
流式解析的验收标准不是“收到了几块数据”,而是 buffer 最终被完整消费,decode 得到合法对象,required 字段通过,最后才由 done 推进到完成状态。把这几件事拆开后,半截 JSON、提前断流和缺字段都会有自己的错误路径,重试也不会误把不完整结果当成成功。
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习