长上下文与流式响应防截断避免 JSON 生成中途夭折在利用大模型生成包含大量排版坐标、多个段落和贴纸列表的复杂手账画报时前端与后端常遇到一个令人沮丧的异常生成到第 80% 的时候流式连接突然中断或者由于达到了max_tokens限制返回了一个末尾没有闭合的花括号的残缺 JSON。直接丢给JSON.parse毫无疑问会触发SyntaxError导致整张排版画布彻底失效。为了在长文本与复杂结构生成场景下实现“100% 不夭折的流式防御”我在边缘中继网关中设计了一套**“流式增量语法树解析Streaming JSON AST 尾部自动闭合算法Auto Bracket Completion”**。-------------------------------------------------------------------- | 流式 JSON 增量解析与防截断防御架构 | -------------------------------------------------------------------- | [边缘 SSE 流式中继: 逐字接收模型吐出的 Token 块] | | | | | v (每一帧经过 Stream-JSON-Parser 状态机增量解析) | | [实时更新已就绪的有效字段 (如 title 已完整, 立即驱动前端渲染)] | | | | | v (若中途网络断开或遭遇 max_tokens 强制截断) | | [触发智能状态机闭合算法:] | | ├── 1. 扫描未闭合的未完成字符串 (补齐闭合双引号 ) | | ├── 2. 依据符号栈 (Symbol Stack) 逆序补齐缺失的 ] 和 } | | └── 3. 剥离最后那个未完成的残缺键值对 | | | | | v (安全解析为合法 JSON 并交付前端保留 80% 已生成内容) | --------------------------------------------------------------------1. 增量解析状态机为什么不要等全部吐完才 Parse传统的处理方式是等待整个 2000 字的流式传输彻底结束再调用一次JSON.parse。这不仅让流式失去了“即时渐进展现”的意义还把所有的风险都押注在最后一个 Token 的完整性上。通过使用流式 JSON 解析库如streamparser/json只要大模型吐出了title: 海边日落这个字段就会立刻被前端响应式捕获文字在毫秒级内直接浮现在手账纸上。2. 状态机尾部括号逆序自动补齐算法当流式被非正常掐断时我们用一个纯 TypeScript 算法在内存中完成数据拯救export function repairIncompleteJson(incompleteStr: string): string { let inString false; let isEscaped false; const stack: string[] []; // 1. 扫描字符串维护花括号与方括号的嵌套栈 for (let i 0; i incompleteStr.length; i) { const char incompleteStr[i]; if (isEscaped) { isEscaped false; continue; } if (char \\) { isEscaped true; continue; } if (char ) { inString !inString; continue; } if (!inString) { if (char { || char [) { stack.push(char); } else if (char } || char ]) { stack.pop(); } } } let repaired incompleteStr.trim(); // 2. 如果截断发生在字符串内部先补齐双引号 if (inString) { repaired ; } // 3. 如果末尾留下了悬空的逗号或冒号剥离非法尾随字符 repaired repaired.replace(/[:,]\s*$/, ); // 4. 根据栈内剩余的开括号逆序补齐对应的闭合括号 while (stack.length 0) { const openChar stack.pop(); if (openChar {) { repaired }; } else if (openChar [) { repaired ]; } } return repaired; }3. 前端渐进式容错体验有了这套算法即使大模型在生成到第 5 张贴纸时因网络抖动突然断开系统也能自动把前面的 4 张贴纸和完整文字安全闭环并渲染出来。用户看到的是一张**“虽然少了一点点装饰、但核心内容完整呈现的美丽手账”**而不是一个冰冷的“请求中断请重试”红牌。把容错做到极致才能在不完美的基础设施上构建出近乎完美的用户体验。