1. 别急着接SDK先搞清楚H5里的AI流式响应到底卡在哪做AI聊天功能很多前端朋友第一次接后端流式接口时都会遇到同一个困惑明明后端数据是一段一段吐出来的自己也用了EventSource或者fetch的ReadableStream页面上的效果却还是像憋大招——等好几秒才一次性蹦出一整段文字中间没有任何逐字出现的过程。我早先在给某模拟项目X做移动端H5客服助手时也踩过这个坑。后来把整个链路从网络层、数据解析层到渲染层全捋了一遍才明白H5里处理AI聊天流式数据难点根本不在怎么拿到流而在拿到流之后怎么低成本地解析、按节奏渲染、并且在弱网和中途打断时不让体验崩掉。这篇文章不聊怎么调大模型API也不聊后端的SSE怎么发专注讲前端H5这一侧的事。内容包括为什么response.body拿到的流不能被直接await完再处理流式数据解析时最容易做错的TextDecoder用法打字机效果为什么不能简单setInterval以及正确的节流方案用户点击停止生成后前端需要做哪些清理动作长文本高算量场景下怎么避免页面卡顿、白屏、内存暴涨弱网、异常中断、半截JSON这些脏数据怎么兜底整体思路适合已经会用fetch、了解Promise基础的前端开发者如果你正在做AI对话类产品照着这篇文章可以少走不少弯路。2. 流式方案选型SSE与WebSocket别一上来就选WebSocket先讲一个容易被带偏的选型问题。很多人听到流式就觉得必须上WebSocket实际上AI聊天场景大多数后端都提供的是SSEServer-Sent Events这是一种基于HTTP的推送协议服务端可以持续向客户端发送数据直到主动断开。2.1 为什么说SSE在AI聊天场景往往更合适从对话需求看AI聊天是用户请求一次模型回复一次的单向长连接服务端向客户端持续输出内容。SSE天生就是干这个的它复用HTTP协议不需要额外的握手协议而且有自动重连机制。实现起来也简单后端不需要维护状态化的连接池。举个例子有次我接一个快速原型后端同事临时用Node写了兼容OpenAI格式的流式接口返回的是text/event-stream我用fetch就能直接消费前后端联调一共花了不到半小时。如果这时候换成WebSocket得处理连接建立、心跳保活、消息编解码明显更重。WebSocket真正适合的是双向高频交互场景比如在线协作、多人同步、实时游戏互相发指令。聊天里大多数情况都是用户发一句、AI回一段双方并行的概率很低用WebSocket属于杀鸡用牛刀。所以如果后端已经提供了SSE接口H5前端直接用就好。如果后端硬要WebSocket那就需要评估是否真的有双向低延迟通信的需求没有的话可以坚持一下SSE。2.2 用fetch消费SSE流比EventSource好在哪浏览器原生有个EventSource只能做GET请求而且不能自定义请求头。AI场景里常需要带Token鉴权、传用户ID、指定模型参数这些用EventSource基本没法玩。因此更通用的做法是用fetch配合ReadableStream处理。fetch(/api/chat/stream, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${token}, }, body: JSON.stringify({ prompt: 你好 }), signal: AbortSignal.timeout(60000), }).then((response) { if (!response.ok) { throw new Error(HTTP ${response.status}) } // response.body 是 ReadableStream可以持续读取 return response.body.getReader() })这样做的好处是请求方式、请求头、超时控制、中断信号全部都能自己掌握。缺点是需要自己解析SSE格式的数据但解析逻辑并不复杂下面会讲。3. SSE数据流的完整处理链路从原始字节到UI文字拿到ReadableStream只是第一步接下来要做的核心事情有三个解码字节、切分事件帧、解析JSON载荷。3.1 字节解码必须用TextDecoder且要设置stream为trueReadableStream默认输出的是Uint8Array字节块。如果直接用new TextDecoder().decode(chunk)在中文内容里会出现乱码因为一个汉字通常是3个字节流式传输时可能把一个字的字节切到两个chunk里。正确做法是const decoder new TextDecoder(utf-8) while (true) { const { value, done } await reader.read() if (done) break const text decoder.decode(value, { stream: true }) // 注意这里的 { stream: true }避免跨chunk的字节被截断 } // 最后一定要再调一次 decoder.decode()清空缓冲区 const rest decoder.decode()TextDecoder加stream: true后会把没凑完整的多字节字符缓存起来下一次decode时再拼接这样切在任意位置的汉字都能正确还原。这是流式解析最容易踩的一个坑很多问为什么AI回答里偶尔出现一个乱码字的问题根因就在这里。3.2 SSE事件帧的边界切分SSE协议规定消息之间用空行\n\n分隔每条事件可以包含多行形如data: {choices:[{delta:{content:你}}]} data: {choices:[{delta:{content:好}}]}所以拿到字符串后需要按双换行切块再逐行处理。每行以data:开头的才是有效载荷需要去掉前缀再解析。function parseSSEChunk(text) { const blocks text.split(\n\n) const events [] for (const block of blocks) { const lines block.split(\n) const dataLines lines.filter((l) l.startsWith(data:)) if (!dataLines.length) continue const data dataLines.map((l) l.slice(5).trim()).join(\n) if (data [DONE]) continue try { const json JSON.parse(data) events.push(json) } catch (e) { // 半截JSON直接丢弃等下一个块继续 } } return events }注意两点一是同一事件的数据行可能有多行需要拼起来再解析二是[DONE]这种结束标记有些后端会发有些不发前端最好都能兼容。提示我在接入过程中发现不同的后端框架对SSE的格式实现略有差异。有的会在每条消息后发\r\n\r\n有的只发\n\n有的会把data:写成data全角冒号这是后端bug。解析时最好统一做一下兼容处理比如把\r\n先替换成\n再按\n\n切分。3.3 增量内容与最终消息的区分现在主流的大模型流式接口比如OpenAI兼容协议返回格式通常是choices[0].delta.content。delta是增量就是说每次事件里只有新增的几个字。不过实际项目中有三种情况纯增量模式每帧只有新增内容前端直接追加渲染全量叠加模式每帧带的是到当前为止的完整内容前端要整体替换两者混合有的帧是增量有的帧是全量比如角色信息、工具调用我在处理某图像处理Demo的对话日志时遇到过混用的情况。稳妥做法是维护一个状态字段判断后端返回的是delta还是message分别走追加和替换逻辑。如果不做区分用户会看到AI回答的同一段文字被反复重绘闪得厉害。4. 打字机渲染的正确姿势从无脑追加到帧率控制的演进流式数据解析出来了如果直接把每段文字appendChild或者textContent 在桌面端可能还好但H5页面在手机上极容易卡顿。因为每帧数据到达频率可能高达每30ms一次而浏览器渲染一帧的时间一般是16.6ms全量重绘根本吃不消。更合理的方式是实现一个消息队列 定时刷盘的渲染机制。4.1 数据到达频率与渲染频率解耦核心思路是把从网络到达的数据推入一个缓冲区然后用requestAnimationFrame控制渲染节奏每帧只把缓冲区里攒下的内容一次性渲染到页面上。function createTypingStream(onContent) { let buffer let scheduled false function flush() { if (!buffer) { scheduled false return } const text buffer buffer scheduled false onContent(text) // 在这里把 content 追加到页面节点 } return { push(text) { buffer text if (!scheduled) { scheduled true requestAnimationFrame(flush) } }, end() { flush() } } }这样做的好处在于即便后端一秒钟推送了30个片段页面也只会跟随屏幕刷新率重绘顶多每秒60次。而且requestAnimationFrame在标签页切到后台时会自动暂停不会空耗性能。实际测试下来长对话页面文字滚动顺滑很多帧数从掉到20帧提升到稳定55帧以上。4.2 不做防抖会带来什么问题有朋友会问我直接用setTimeout防抖不行吗其实也行但有一些小问题setTimeout的延迟时间如果设得太短比如50ms遇到高频数据仍可能堆积如果设得太长比如300ms用户能看到明显的一顿一顿效果观感变差页面切换到后台时setTimeout还是会跑不必要的计算仍然发生requestAnimationFrame则刚好跟着显示器的节奏走而且切后台自动暂停。唯一要注意的是它不一定每秒恰好60次有些高刷手机是90帧、120帧但这不影响使用因为流式文本追加本来不需要严格等间隔。4.3 快速滚动的处理聊天过程中用户通常希望最新的文字自动出现在视口里这时需要控制滚动容器到底部。但如果每一帧都滚动一次连续滚动会带来比较大的性能开销而且有可能打断用户正在往上翻看历史记录的操作。我的做法是记录用户是否在视口底部只有用户停留在底部时才执行滚动。如果用户上翻查看历史内容自动滚动立即停止。function scrollToBottomIfNeeded(container) { const distance container.scrollHeight - container.scrollTop - container.clientHeight if (distance 24) { container.scrollTop container.scrollHeight } }这个距离底部小于24px才滚动的阈值是我试出来的个人经验值不同设计可以微调。核心目的是避免不分情况强制滚动造成的糟糕体验。5. 流式对话中停止生成按钮从信号传递到资源回收的完整链路AI流式对话的一个刚需功能是用户觉得AI答得太啰嗦、方向不对点一下停止请求立刻中断后面没吐完的内容全部丢弃页面停留在已有文字上。5.1 AbortController的正确用法fetch支持通过AbortController中断请求。比较稳妥的做法是将controller存到组件的实例或者一个全局管理Map里点击停止时调用abortconst controller new AbortController() fetch(/api/chat/stream, { signal: controller.signal, }) // 停止生成 function stopGenerate() { controller.abort() }有个细节是abort之后reader.read()会抛出一个AbortError的DOMException需要在循环里捕获并当作正常结束来处理而不是把它传到全局错误处理。while (true) { try { const { value, done } await reader.read() if (done) break // 处理数据 } catch (err) { if (err.name AbortError) { break // 用户主动中断正常结束 } throw err } }5.2 中断后的状态清理中断不能只停留在请求断了界面上还有几件事要同步处理把停止生成按钮隐藏/禁用恢复可以输入的状态如果有加载动画、光标闪烁动画要停掉当前AI消息的正在生成标记要置为完成如果有声音提示、震动反馈也要在这里处理我在模拟项目X里用过一个简单的状态机idle-streaming-done/aborted。任何状态下点停止都只允许从streaming流转到aborted避免连点两次造成重复的abort操作。5.3 结束标记的处理不能依赖[DONE]前面提过不同的后端实现里流结束的标记不同。有的会发一行data: [DONE]有的会在传输完毕后正常关闭流done为true还有的会直接断开连接导致浏览器出现网络错误。所以不能把[DONE]当作唯一的结束判定。我在实现里是同时监听两个信号parser是否收到[DONE]reader是否返回done: true两者只要有一个触发都进入结束流程。另外还要设置一个兜底的超时时间比如60秒无数据自动结束或者报错避免后端进程挂死、连接半开不闭导致的永远加载中。6. 长文本渲染性能从DOM追加到虚拟滚动与CSS处理AI聊天很容易出现几千字的长回复尤其在H5里连续把几千字全部渲染进页面会出现卡顿和内存占用暴涨。这不是React或Vue的错根源是浏览器在渲染大文本、重排长列表时的天然开销。6.1 消息节点不要无脑重建很多框架写法是setState({ text: currentText })每次流式内容更新都把整个消息组件重新渲染。高频更新下组件Diff和DOM重建开销巨大在低端安卓机上会非常明显。一个比较实用的优化是把消息拆成外壳节点和内容节点外壳不随内容频繁变更内容节点只更新自己的textContent。如果用的是原生DOM操作直接对现有节点做textContent增量追加跳过内层模板渲染。如果是Vue/React可以用v-html直接操作已存在节点但要非常注意XSS风险AI内容不确定来源不建议直接v-html。我实际比较推荐的做法是要显示的文本在进入渲染前做一次纯文本化处理把、转义代码块内容转成受控的富文本节点。这样既避免XSS也避免每次更新时全量解析HTML导致的性能问题。6.2 虚拟滚动不是第一优先级的方案有人会说几千字文本为什么不直接上虚拟滚动我的经验是虚拟滚动对很多条短消息的场景价值大对一条超长消息的场景价值反而有限。因为它要实时计算每个节点的高度而流式文本高度在动态变化中虚拟列表很容易频繁触发重算复杂度很高。如果真遇到超长文本更简单的做法是对单条消息的内容做折叠/展开处理超过一定字数自动折叠把代码块、长JSON等独立节点懒渲染滚动到可视区附近再填充内容6.3 文本节点拆分与样式隔离流式文本如果包含Markdown比较稳妥的做法是分块渲染先渲染纯文本按照markdown规则解析的节点再对代码块等特殊部分单独处理。流式更新时如果每次都重新解析全文在长文本下代价很大。我的一个优化技巧是解析器按一定规则将内容切分成纯文本段落和特殊块代码/表格/公式每次增量到达只更新最后一个未闭合的段落块已闭合的段落块不再重新解析。这让长文本流式解析的CPU占用下降了将近一半。7. 弱网、半截JSON与异常中断的兜底策略真实线上环境比调试环境复杂得多弱网、代理超时、后端重启、进程OOM都会把好好的SSE流搞得乱七八糟。处理流式数据时以下问题要提前想到。7.1 半截JSON的容错前面解析SSE时提到半截JSON要直接丢弃。但有一种情况是一个SSE事件本身没传完连接就断了解析器在下一轮才收到剩余字节。这时不能让解析状态错乱。做法是引入一个pendingText变量把每次decode出来的字符串先和之前的残留拼到一起再做分块解析。解析不掉的尾巴继续留给下一轮。如果连接最终中断残留在缓冲区里的数据直接清空不回显给用户。7.2 自动重连与续传的取舍有些场景希望断网后自动重连并继续生成。这对AI对话来说会比较麻烦因为后端大模型的状态可能已经丢失重连后重新发起请求可能会重复生成。所以在对话场景里我通常选择不自动续传、只提示用户可重新发送反而更简单稳妥。如果你的产品确实需要断线续传比如长文档生成那得前后端配合前端记录已渲染文本的字符数后端支持从指定偏移量恢复。这一个功能设计量不小前端侧只能作为辅助。7.3 半程无数据时的超时与心跳SSE连接建立后如果长时间没有任何数据到达要区分是模型在思考还是连接已死。最直接的方法记录最后一条数据到达的时间每5秒检查一次。如果超过阈值无数据先尝试发一个ping到后端仍无响应则判定超时。阈值我习惯设为30秒因为某些大模型思考时间确实较长但一般不会超过这个值。setInterval(() { if (Date.now() - lastDataTime 30000) { controller.abort() showError(响应超时请稍后重试) } }, 5000)注意这个定时器在消息完成后记得清除不然页面停留也会一直跑。7.4 后端报错与半程HTTP状态码SSE流有个特点HTTP状态码通常是在连接建立时就返回了200后续的错误只能靠流内部传递。但有一种情况是网关层在流式传输中途返回错误比如401过期这时response.body可能正常但后续没有数据。前端一定要监听两个点response.ok为false时直接走错误处理不要尝试读流流读取过程中reader.read()抛出异常要区分是网络错误还是协议错误分别展示不同的提示文案注意在H5弱网场景里有时read()会抛TypeError: Failed to fetch这种错误通常不是后端逻辑问题而是网关或浏览器层断连。提示用户网络连接不稳定比服务器错误更准确也更友好。8. 关于状态管理、并发对话与缓存去重聊完底层最后串一下上层设计。8.1 并发对话的管理有些AI产品允许同时开多个对话窗口此时如果用户快速切换旧的流式请求还在跑新窗口又发起请求容易出现状态串台。我建议维护一个Mapkey是会话IDvalue是AbortController。切走会话时通知用户生成仍在继续切回时数据还在累积如果用户关闭会话则直接abort回收。8.2 消息滚动的去重流式追加时偶尔会出现重复内容。原因可能是后端重试、网关重发或者前端在重连后重复处理了同一事件。前端可以在追加时做一个简单校验记录已渲染的末尾字符与新内容的前缀做比对若重复则截断重复部分再追加。这个逻辑成本极低却能在一些异常场景里显著减少内容重复两遍的体验问题。8.3 响应内容的展示顺序有些AI会先输出思考过程再输出正文或者穿插引用、工具调用信息。流式情况下如果后端把不同类型的数据混在同一个流里前端要做的是按类型分发到不同容器避免思考和正文混在一起显示。我在处理某跨平台系统的日志分析功能时把类型字段放到事件解析的分发层效率比在UI层反复判断高得多。9. 实测下来的性能参考与经验总结最后给一个真实的项目参考数据方便大家心里有底。我在某模拟项目X里做了两次优化前后的对比指标优化前无缓冲直接渲染优化后RAF缓冲渲染低端安卓机渲染帧率20~30帧滚动明显卡顿55~60帧跟手顺滑3000字长回复渲染耗时约3.8秒约1.9秒页面内存峰值约460MB约290MBCPU持续占用60%~80%30%~45%每一项优化带来的收益都挺直观。当然不同机型、不同浏览器有差异但方向是一致的流式数据的处理核心永远是减少不必要的工作量把网络到达的频率和UI渲染的频率解耦把解析和渲染分开把异常中断当成正常流程来处理。如果让我给刚接触AI流式聊天的新手一个最直接的行动建议那就是先把TextDecoder和requestAnimationFrame两个点吃透再谈其它。前者解决字对不对的问题后者解决卡不卡的问题。这两个点做到位H5里的AI聊天体验基本就合格了一大半。我自己在最初几次调试时还踩过一个比较隐蔽的坑在React StrictMode下组件会渲染两次如果副作用没有清理干净同一个流式请求会发出两份页面出现两段AI回复。这个问题排查了很久本质是Effect cleanup里忘了调abort()。所以如果你用的是React 18记得把AbortController的清理动作放在useEffect的返回值里这是很多线上事故的隐藏元凶。流式数据本身并不复杂复杂的是在移动端这种资源受限的环境里把持续抵达的数据和有限的渲染能力调和好。这篇文章里讲到的每一条经验都是从真实项目中一行一行调试出来的希望可以帮你少走一些弯路。如果你在接入过程中遇到更奇怪的问题欢迎把你的现象和代码片段分享出来我们一起来拆一拆。