说实话，实现AI Chat的流式打字效果挺有意思的，咱就是说让聊天机器人像真人一样打字，体验一下子就上来了。

在 AI 对话场景里用户Zui敏感的不是“总耗时”，而是“多久kan到第一个字”。

流式输出Zui大的价值，就是让回复边生成边展示，显著提升体感速度。

普通接口是 AI 思考完，一次性返回全部内容；流式输出是 AI 边思考边返回，逐字/逐句推送。

你会发现，流式输出的等待体验geng好，不会让用户以为程序卡了。

前端实现流式输出的核心，不是“用了 SSE”这么简单，而是：逐行解析 data: 事件，拿到 JSON 后按字段分发逻辑。

后端在推，但前端不让主线程喘气，就会“kan起来一次性渲染”。

所以我们需要requestAnimationFrame让出一帧，观感差距非常明显。

这套实现走的是 text/event-stream，后端按行推送：

data: {"content": "你"}data: {"content": "好"}data: {"done": true, "conversation_id": "conv_abc123", "message_id": "msg_001"}

前端只需要抓住一个核心：逐行解析 data: ，拿到 JSON 后按字段分发逻辑。

export async function streamChat { // ... const reader = res.body.getReader const decoder = new TextDecoder let buffer = "" let fullText = "" while { const { done, value } = await reader.read if buffer += decoder.decode const lines = buffer.split buffer = lines.pop || "" for { if ) continue const raw = line.slice.trim if continue const data = JSON.parse // 处理数据 } if break } } reader.read实际在干什么

res.body是一个ReadableStream

reader.read每次返回的是：done: boolean；value: Uint8Array

这块字节是网络底层随缘给你的：「收到多少就给多少」，会受网络层拆包/粘包影响。

"data:{...} data:{...} "

data: {"content": "你"}data: {"content": "好"}

前端实现流式输出的关键代码：

const assistantIdx = messages.value.length - await streamChat(content, history, { conversationId: activeConversationId.value, onChunk: => { // geng新消息 }, onDone: => { // 处理完成逻辑 } }) 为什么要“替换对象”而不是直接赋值字段？

在高频 chunk geng新下直接msg.content = fullText,可Neng让视图geng新不稳定。 通过 { ...msg, content: fullText },Ke以geng稳定地触发 Vue 响应式刷新。

要 yieldToUI，即把主线程还给浏览器一帧，用requestAnimationFrame 实现。

const yieldToUI =  => new Promise => requestAnimationFrame)
if  {
fullText += data.content
onChunk?.
await yieldToUI
}

这技巧Ke以缓解 “后端虽然分片返回，但前端因为连续计算导致批量渲染 ” 的问题。 说白了就是得让 UI Neng及时geng新，别卡顿。 哈哈，这么搞下来你的 Chat 页面就不只是 “Neng用 ” 了而是 “体验贼棒 ” ！ 各大模子返回的 流式 数据格式不一样 , 实现 打字效果 . let url ='https://api.coze.cn/v3/ chat '//这里使用的是抖音扣子模型 . //simulateGPTResponse// 打字 效果、方法请往下kan . 今天的目标 :搞懂 流式 输出的原理 ,用 JS 和 Python 分别 实现 后端流式调用 ,再用前端代码Zuo出 打字 机效果。 Ru果要在新项目快速落地，Ke以按这个结构拆分： 你会得到一个职责清晰、可维护的 流式 聊天前端架构。 完整代码就不贴了自己动手尝试吧！害，总得自己试试才知道哪里还有坑嘛～ 咱就是说实现到这个程度，Yi经Neng让用户感觉hen丝滑了。 你要是还想geng进一步优化，那就得深入研究各种 edge cases 了。 比如网络波动啊，后端异常啊，这些dou要考虑到。 但说实话，大部分场景下Zuo到这里就够了。