设计AI聊天页时，如何应对耗时一整天的五种流式格式难题？

这篇聊聊我在这个组件里踩过的坑，以及再说说 不忍卒读。 沉淀下来的一套状态机 + 流式 渲染方案。

流式格式的“五巨头”挑战

在开发AI聊天界面时 我原本以为只是简单地接入API，后来啊却在“流式格式”这个看似不起眼的环节上摔了个大跟头。本以为是轻松愉快的周末项目，后来啊却变成了一场耗时一整天的“格式大战”，太治愈了。。

第一个坑：“温柔陷阱”

一开始， 我天真地以为只要接入OpenAI，一切都会顺其自然。毕竟API设计得如此优雅， 等着瞧。 让我误以为其他平台也会“乖乖兼容”。只是现实狠狠地打了我一巴掌。

API返回格式清晰、结构简单，是“流式响应”的典范。但其他平台呢，拯救一下。？

• Claude返回的是SSE格式， 但事件类型五花八门，解析起来像在解谜。
• Gemini不走寻常路， 返回的不是标准SSE，而是JSON数组，让人摸不着头脑。
• DeepSeek号称“OpenAI兼容”，后来啊却在细节上各种“不兼容”。
• Kimi看似兼容， 但结束信号的处理方式却略有不同，稍有不慎就踩雷。
• Qwen虽然没踩坑，但它的“思考过程”字段 reasoning_content 会让人误以为AI卡住了。

第二个坑：字段的“断章取义”

你以为只要把数据从API里取出来就完事了？太天真了。有些模型会返回一些“半成品”数据， 比如Claude的 content_block_delta你得一层层地去挖，才能找到真正要显示的文本。而有些模型， 比如DeepSeek，甚至会把“思考过程”藏在 reasoning_content 里让人误以为AI“卡住”了，挖野菜。。