實(shí)戰(zhàn)：SSE解析、打字機(jī)渲染與性能優(yōu)化)
1. 別急著接SDK先搞清楚H5里的AI流式響應(yīng)到底卡在哪做AI聊天功能很多前端朋友第一次接后端流式接口時都會遇到同一個困惑明明后端數(shù)據(jù)是一段一段吐出來的自己也用了EventSource或者fetch的ReadableStream頁面上的效果卻還是像憋大招——等好幾秒才一次性蹦出一整段文字中間沒有任何逐字出現(xiàn)的過程。我早先在給某模擬項目X做移動端H5客服助手時也踩過這個坑。后來把整個鏈路從網(wǎng)絡(luò)層、數(shù)據(jù)解析層到渲染層全捋了一遍才明白H5里處理AI聊天流式數(shù)據(jù)難點(diǎn)根本不在怎么拿到流而在拿到流之后怎么低成本地解析、按節(jié)奏渲染、并且在弱網(wǎng)和中途打斷時不讓體驗(yàn)崩掉。這篇文章不聊怎么調(diào)大模型API也不聊后端的SSE怎么發(fā)專注講前端H5這一側(cè)的事。內(nèi)容包括為什么response.body拿到的流不能被直接await完再處理流式數(shù)據(jù)解析時最容易做錯的TextDecoder用法打字機(jī)效果為什么不能簡單setInterval以及正確的節(jié)流方案用戶點(diǎn)擊停止生成后前端需要做哪些清理動作長文本高算量場景下怎么避免頁面卡頓、白屏、內(nèi)存暴漲弱網(wǎng)、異常中斷、半截JSON這些臟數(shù)據(jù)怎么兜底整體思路適合已經(jīng)會用fetch、了解Promise基礎(chǔ)的前端開發(fā)者如果你正在做AI對話類產(chǎn)品照著這篇文章可以少走不少彎路。2. 流式方案選型SSE與WebSocket別一上來就選WebSocket先講一個容易被帶偏的選型問題。很多人聽到流式就覺得必須上WebSocket實(shí)際上AI聊天場景大多數(shù)后端都提供的是SSEServer-Sent Events這是一種基于HTTP的推送協(xié)議服務(wù)端可以持續(xù)向客戶端發(fā)送數(shù)據(jù)直到主動斷開。2.1 為什么說SSE在AI聊天場景往往更合適從對話需求看AI聊天是用戶請求一次模型回復(fù)一次的單向長連接服務(wù)端向客戶端持續(xù)輸出內(nèi)容。SSE天生就是干這個的它復(fù)用HTTP協(xié)議不需要額外的握手協(xié)議而且有自動重連機(jī)制。實(shí)現(xiàn)起來也簡單后端不需要維護(hù)狀態(tài)化的連接池。舉個例子有次我接一個快速原型后端同事臨時用Node寫了兼容OpenAI格式的流式接口返回的是text/event-stream我用fetch就能直接消費(fèi)前后端聯(lián)調(diào)一共花了不到半小時。如果這時候換成WebSocket得處理連接建立、心跳?；?、消息編解碼明顯更重。WebSocket真正適合的是雙向高頻交互場景比如在線協(xié)作、多人同步、實(shí)時游戲互相發(fā)指令。聊天里大多數(shù)情況都是用戶發(fā)一句、AI回一段雙方并行的概率很低用WebSocket屬于殺雞用牛刀。所以如果后端已經(jīng)提供了SSE接口H5前端直接用就好。如果后端硬要WebSocket那就需要評估是否真的有雙向低延遲通信的需求沒有的話可以堅持一下SSE。2.2 用fetch消費(fèi)SSE流比EventSource好在哪瀏覽器原生有個EventSource只能做GET請求而且不能自定義請求頭。AI場景里常需要帶Token鑒權(quán)、傳用戶ID、指定模型參數(shù)這些用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可以持續(xù)讀取 return response.body.getReader() })這樣做的好處是請求方式、請求頭、超時控制、中斷信號全部都能自己掌握。缺點(diǎn)是需要自己解析SSE格式的數(shù)據(jù)但解析邏輯并不復(fù)雜下面會講。3. SSE數(shù)據(jù)流的完整處理鏈路從原始字節(jié)到UI文字拿到ReadableStream只是第一步接下來要做的核心事情有三個解碼字節(jié)、切分事件幀、解析JSON載荷。3.1 字節(jié)解碼必須用TextDecoder且要設(shè)置stream為trueReadableStream默認(rèn)輸出的是Uint8Array字節(jié)塊。如果直接用new TextDecoder().decode(chunk)在中文內(nèi)容里會出現(xiàn)亂碼因?yàn)橐粋€漢字通常是3個字節(jié)流式傳輸時可能把一個字的字節(jié)切到兩個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的字節(jié)被截斷 } // 最后一定要再調(diào)一次 decoder.decode()清空緩沖區(qū) const rest decoder.decode()TextDecoder加stream: true后會把沒湊完整的多字節(jié)字符緩存起來下一次decode時再拼接這樣切在任意位置的漢字都能正確還原。這是流式解析最容易踩的一個坑很多問為什么AI回答里偶爾出現(xiàn)一個亂碼字的問題根因就在這里。3.2 SSE事件幀的邊界切分SSE協(xié)議規(guī)定消息之間用空行\(zhòng)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直接丟棄等下一個塊繼續(xù) } } return events }注意兩點(diǎn)一是同一事件的數(shù)據(jù)行可能有多行需要拼起來再解析二是[DONE]這種結(jié)束標(biāo)記有些后端會發(fā)有些不發(fā)前端最好都能兼容。提示我在接入過程中發(fā)現(xiàn)不同的后端框架對SSE的格式實(shí)現(xiàn)略有差異。有的會在每條消息后發(fā)\r\n\r\n有的只發(fā)\n\n有的會把data:寫成data全角冒號這是后端bug。解析時最好統(tǒng)一做一下兼容處理比如把\r\n先替換成\n再按\n\n切分。3.3 增量內(nèi)容與最終消息的區(qū)分現(xiàn)在主流的大模型流式接口比如OpenAI兼容協(xié)議返回格式通常是choices[0].delta.content。delta是增量就是說每次事件里只有新增的幾個字。不過實(shí)際項目中有三種情況純增量模式每幀只有新增內(nèi)容前端直接追加渲染全量疊加模式每幀帶的是到當(dāng)前為止的完整內(nèi)容前端要整體替換兩者混合有的幀是增量有的幀是全量比如角色信息、工具調(diào)用我在處理某圖像處理Demo的對話日志時遇到過混用的情況。穩(wěn)妥做法是維護(hù)一個狀態(tài)字段判斷后端返回的是delta還是message分別走追加和替換邏輯。如果不做區(qū)分用戶會看到AI回答的同一段文字被反復(fù)重繪閃得厲害。4. 打字機(jī)渲染的正確姿勢從無腦追加到幀率控制的演進(jìn)流式數(shù)據(jù)解析出來了如果直接把每段文字appendChild或者textContent 在桌面端可能還好但H5頁面在手機(jī)上極容易卡頓。因?yàn)槊繋瑪?shù)據(jù)到達(dá)頻率可能高達(dá)每30ms一次而瀏覽器渲染一幀的時間一般是16.6ms全量重繪根本吃不消。更合理的方式是實(shí)現(xiàn)一個消息隊列 定時刷盤的渲染機(jī)制。4.1 數(shù)據(jù)到達(dá)頻率與渲染頻率解耦核心思路是把從網(wǎng)絡(luò)到達(dá)的數(shù)據(jù)推入一個緩沖區(qū)然后用requestAnimationFrame控制渲染節(jié)奏每幀只把緩沖區(qū)里攢下的內(nèi)容一次性渲染到頁面上。function createTypingStream(onContent) { let buffer let scheduled false function flush() { if (!buffer) { scheduled false return } const text buffer buffer scheduled false onContent(text) // 在這里把 content 追加到頁面節(jié)點(diǎn) } return { push(text) { buffer text if (!scheduled) { scheduled true requestAnimationFrame(flush) } }, end() { flush() } } }這樣做的好處在于即便后端一秒鐘推送了30個片段頁面也只會跟隨屏幕刷新率重繪頂多每秒60次。而且requestAnimationFrame在標(biāo)簽頁切到后臺時會自動暫停不會空耗性能。實(shí)際測試下來長對話頁面文字滾動順滑很多幀數(shù)從掉到20幀提升到穩(wěn)定55幀以上。4.2 不做防抖會帶來什么問題有朋友會問我直接用setTimeout防抖不行嗎其實(shí)也行但有一些小問題setTimeout的延遲時間如果設(shè)得太短比如50ms遇到高頻數(shù)據(jù)仍可能堆積如果設(shè)得太長比如300ms用戶能看到明顯的一頓一頓效果觀感變差頁面切換到后臺時setTimeout還是會跑不必要的計算仍然發(fā)生requestAnimationFrame則剛好跟著顯示器的節(jié)奏走而且切后臺自動暫停。唯一要注意的是它不一定每秒恰好60次有些高刷手機(jī)是90幀、120幀但這不影響使用因?yàn)榱魇轿谋咀芳颖緛聿恍枰獓?yán)格等間隔。4.3 快速滾動的處理聊天過程中用戶通常希望最新的文字自動出現(xiàn)在視口里這時需要控制滾動容器到底部。但如果每一幀都滾動一次連續(xù)滾動會帶來比較大的性能開銷而且有可能打斷用戶正在往上翻看歷史記錄的操作。我的做法是記錄用戶是否在視口底部只有用戶停留在底部時才執(zhí)行滾動。如果用戶上翻查看歷史內(nèi)容自動滾動立即停止。function scrollToBottomIfNeeded(container) { const distance container.scrollHeight - container.scrollTop - container.clientHeight if (distance 24) { container.scrollTop container.scrollHeight } }這個距離底部小于24px才滾動的閾值是我試出來的個人經(jīng)驗(yàn)值不同設(shè)計可以微調(diào)。核心目的是避免不分情況強(qiáng)制滾動造成的糟糕體驗(yàn)。5. 流式對話中停止生成按鈕從信號傳遞到資源回收的完整鏈路AI流式對話的一個剛需功能是用戶覺得AI答得太啰嗦、方向不對點(diǎn)一下停止請求立刻中斷后面沒吐完的內(nèi)容全部丟棄頁面停留在已有文字上。5.1 AbortController的正確用法fetch支持通過AbortController中斷請求。比較穩(wěn)妥的做法是將controller存到組件的實(shí)例或者一個全局管理Map里點(diǎn)擊停止時調(diào)用abortconst controller new AbortController() fetch(/api/chat/stream, { signal: controller.signal, }) // 停止生成 function stopGenerate() { controller.abort() }有個細(xì)節(jié)是abort之后reader.read()會拋出一個AbortError的DOMException需要在循環(huán)里捕獲并當(dāng)作正常結(jié)束來處理而不是把它傳到全局錯誤處理。while (true) { try { const { value, done } await reader.read() if (done) break // 處理數(shù)據(jù) } catch (err) { if (err.name AbortError) { break // 用戶主動中斷正常結(jié)束 } throw err } }5.2 中斷后的狀態(tài)清理中斷不能只停留在請求斷了界面上還有幾件事要同步處理把停止生成按鈕隱藏/禁用恢復(fù)可以輸入的狀態(tài)如果有加載動畫、光標(biāo)閃爍動畫要停掉當(dāng)前AI消息的正在生成標(biāo)記要置為完成如果有聲音提示、震動反饋也要在這里處理我在模擬項目X里用過一個簡單的狀態(tài)機(jī)idle-streaming-done/aborted。任何狀態(tài)下點(diǎn)停止都只允許從streaming流轉(zhuǎn)到aborted避免連點(diǎn)兩次造成重復(fù)的abort操作。5.3 結(jié)束標(biāo)記的處理不能依賴[DONE]前面提過不同的后端實(shí)現(xiàn)里流結(jié)束的標(biāo)記不同。有的會發(fā)一行data: [DONE]有的會在傳輸完畢后正常關(guān)閉流done為true還有的會直接斷開連接導(dǎo)致瀏覽器出現(xiàn)網(wǎng)絡(luò)錯誤。所以不能把[DONE]當(dāng)作唯一的結(jié)束判定。我在實(shí)現(xiàn)里是同時監(jiān)聽兩個信號parser是否收到[DONE]reader是否返回done: true兩者只要有一個觸發(fā)都進(jìn)入結(jié)束流程。另外還要設(shè)置一個兜底的超時時間比如60秒無數(shù)據(jù)自動結(jié)束或者報錯避免后端進(jìn)程掛死、連接半開不閉導(dǎo)致的永遠(yuǎn)加載中。6. 長文本渲染性能從DOM追加到虛擬滾動與CSS處理AI聊天很容易出現(xiàn)幾千字的長回復(fù)尤其在H5里連續(xù)把幾千字全部渲染進(jìn)頁面會出現(xiàn)卡頓和內(nèi)存占用暴漲。這不是React或Vue的錯根源是瀏覽器在渲染大文本、重排長列表時的天然開銷。6.1 消息節(jié)點(diǎn)不要無腦重建很多框架寫法是setState({ text: currentText })每次流式內(nèi)容更新都把整個消息組件重新渲染。高頻更新下組件Diff和DOM重建開銷巨大在低端安卓機(jī)上會非常明顯。一個比較實(shí)用的優(yōu)化是把消息拆成外殼節(jié)點(diǎn)和內(nèi)容節(jié)點(diǎn)外殼不隨內(nèi)容頻繁變更內(nèi)容節(jié)點(diǎn)只更新自己的textContent。如果用的是原生DOM操作直接對現(xiàn)有節(jié)點(diǎn)做textContent增量追加跳過內(nèi)層模板渲染。如果是Vue/React可以用v-html直接操作已存在節(jié)點(diǎn)但要非常注意XSS風(fēng)險AI內(nèi)容不確定來源不建議直接v-html。我實(shí)際比較推薦的做法是要顯示的文本在進(jìn)入渲染前做一次純文本化處理把、轉(zhuǎn)義代碼塊內(nèi)容轉(zhuǎn)成受控的富文本節(jié)點(diǎn)。這樣既避免XSS也避免每次更新時全量解析HTML導(dǎo)致的性能問題。6.2 虛擬滾動不是第一優(yōu)先級的方案有人會說幾千字文本為什么不直接上虛擬滾動我的經(jīng)驗(yàn)是虛擬滾動對很多條短消息的場景價值大對一條超長消息的場景價值反而有限。因?yàn)樗獙?shí)時計算每個節(jié)點(diǎn)的高度而流式文本高度在動態(tài)變化中虛擬列表很容易頻繁觸發(fā)重算復(fù)雜度很高。如果真遇到超長文本更簡單的做法是對單條消息的內(nèi)容做折疊/展開處理超過一定字?jǐn)?shù)自動折疊把代碼塊、長JSON等獨(dú)立節(jié)點(diǎn)懶渲染滾動到可視區(qū)附近再填充內(nèi)容6.3 文本節(jié)點(diǎn)拆分與樣式隔離流式文本如果包含Markdown比較穩(wěn)妥的做法是分塊渲染先渲染純文本按照markdown規(guī)則解析的節(jié)點(diǎn)再對代碼塊等特殊部分單獨(dú)處理。流式更新時如果每次都重新解析全文在長文本下代價很大。我的一個優(yōu)化技巧是解析器按一定規(guī)則將內(nèi)容切分成純文本段落和特殊塊代碼/表格/公式每次增量到達(dá)只更新最后一個未閉合的段落塊已閉合的段落塊不再重新解析。這讓長文本流式解析的CPU占用下降了將近一半。7. 弱網(wǎng)、半截JSON與異常中斷的兜底策略真實(shí)線上環(huán)境比調(diào)試環(huán)境復(fù)雜得多弱網(wǎng)、代理超時、后端重啟、進(jìn)程OOM都會把好好的SSE流搞得亂七八糟。處理流式數(shù)據(jù)時以下問題要提前想到。7.1 半截JSON的容錯前面解析SSE時提到半截JSON要直接丟棄。但有一種情況是一個SSE事件本身沒傳完連接就斷了解析器在下一輪才收到剩余字節(jié)。這時不能讓解析狀態(tài)錯亂。做法是引入一個pendingText變量把每次decode出來的字符串先和之前的殘留拼到一起再做分塊解析。解析不掉的尾巴繼續(xù)留給下一輪。如果連接最終中斷殘留在緩沖區(qū)里的數(shù)據(jù)直接清空不回顯給用戶。7.2 自動重連與續(xù)傳的取舍有些場景希望斷網(wǎng)后自動重連并繼續(xù)生成。這對AI對話來說會比較麻煩因?yàn)楹蠖舜竽Ｐ偷臓顟B(tài)可能已經(jīng)丟失重連后重新發(fā)起請求可能會重復(fù)生成。所以在對話場景里我通常選擇不自動續(xù)傳、只提示用戶可重新發(fā)送反而更簡單穩(wěn)妥。如果你的產(chǎn)品確實(shí)需要斷線續(xù)傳比如長文檔生成那得前后端配合前端記錄已渲染文本的字符數(shù)后端支持從指定偏移量恢復(fù)。這一個功能設(shè)計量不小前端側(cè)只能作為輔助。7.3 半程無數(shù)據(jù)時的超時與心跳SSE連接建立后如果長時間沒有任何數(shù)據(jù)到達(dá)要區(qū)分是模型在思考還是連接已死。最直接的方法記錄最后一條數(shù)據(jù)到達(dá)的時間每5秒檢查一次。如果超過閾值無數(shù)據(jù)先嘗試發(fā)一個ping到后端仍無響應(yīng)則判定超時。閾值我習(xí)慣設(shè)為30秒因?yàn)槟承┐竽Ｐ退伎紩r間確實(shí)較長但一般不會超過這個值。setInterval(() { if (Date.now() - lastDataTime 30000) { controller.abort() showError(響應(yīng)超時請稍后重試) } }, 5000)注意這個定時器在消息完成后記得清除不然頁面停留也會一直跑。7.4 后端報錯與半程HTTP狀態(tài)碼SSE流有個特點(diǎn)HTTP狀態(tài)碼通常是在連接建立時就返回了200后續(xù)的錯誤只能靠流內(nèi)部傳遞。但有一種情況是網(wǎng)關(guān)層在流式傳輸中途返回錯誤比如401過期這時response.body可能正常但后續(xù)沒有數(shù)據(jù)。前端一定要監(jiān)聽兩個點(diǎn)response.ok為false時直接走錯誤處理不要嘗試讀流流讀取過程中reader.read()拋出異常要區(qū)分是網(wǎng)絡(luò)錯誤還是協(xié)議錯誤分別展示不同的提示文案注意在H5弱網(wǎng)場景里有時read()會拋TypeError: Failed to fetch這種錯誤通常不是后端邏輯問題而是網(wǎng)關(guān)或?yàn)g覽器層斷連。提示用戶網(wǎng)絡(luò)連接不穩(wěn)定比服務(wù)器錯誤更準(zhǔn)確也更友好。8. 關(guān)于狀態(tài)管理、并發(fā)對話與緩存去重聊完底層最后串一下上層設(shè)計。8.1 并發(fā)對話的管理有些AI產(chǎn)品允許同時開多個對話窗口此時如果用戶快速切換舊的流式請求還在跑新窗口又發(fā)起請求容易出現(xiàn)狀態(tài)串臺。我建議維護(hù)一個Mapkey是會話IDvalue是AbortController。切走會話時通知用戶生成仍在繼續(xù)切回時數(shù)據(jù)還在累積如果用戶關(guān)閉會話則直接abort回收。8.2 消息滾動的去重流式追加時偶爾會出現(xiàn)重復(fù)內(nèi)容。原因可能是后端重試、網(wǎng)關(guān)重發(fā)或者前端在重連后重復(fù)處理了同一事件。前端可以在追加時做一個簡單校驗(yàn)記錄已渲染的末尾字符與新內(nèi)容的前綴做比對若重復(fù)則截斷重復(fù)部分再追加。這個邏輯成本極低卻能在一些異常場景里顯著減少內(nèi)容重復(fù)兩遍的體驗(yàn)問題。8.3 響應(yīng)內(nèi)容的展示順序有些AI會先輸出思考過程再輸出正文或者穿插引用、工具調(diào)用信息。流式情況下如果后端把不同類型的數(shù)據(jù)混在同一個流里前端要做的是按類型分發(fā)到不同容器避免思考和正文混在一起顯示。我在處理某跨平臺系統(tǒng)的日志分析功能時把類型字段放到事件解析的分發(fā)層效率比在UI層反復(fù)判斷高得多。9. 實(shí)測下來的性能參考與經(jīng)驗(yàn)總結(jié)最后給一個真實(shí)的項目參考數(shù)據(jù)方便大家心里有底。我在某模擬項目X里做了兩次優(yōu)化前后的對比指標(biāo)優(yōu)化前無緩沖直接渲染優(yōu)化后RAF緩沖渲染低端安卓機(jī)渲染幀率20~30幀滾動明顯卡頓55~60幀跟手順滑3000字長回復(fù)渲染耗時約3.8秒約1.9秒頁面內(nèi)存峰值約460MB約290MBCPU持續(xù)占用60%~80%30%~45%每一項優(yōu)化帶來的收益都挺直觀。當(dāng)然不同機(jī)型、不同瀏覽器有差異但方向是一致的流式數(shù)據(jù)的處理核心永遠(yuǎn)是減少不必要的工作量把網(wǎng)絡(luò)到達(dá)的頻率和UI渲染的頻率解耦把解析和渲染分開把異常中斷當(dāng)成正常流程來處理。如果讓我給剛接觸AI流式聊天的新手一個最直接的行動建議那就是先把TextDecoder和requestAnimationFrame兩個點(diǎn)吃透再談其它。前者解決字對不對的問題后者解決卡不卡的問題。這兩個點(diǎn)做到位H5里的AI聊天體驗(yàn)基本就合格了一大半。我自己在最初幾次調(diào)試時還踩過一個比較隱蔽的坑在React StrictMode下組件會渲染兩次如果副作用沒有清理干凈同一個流式請求會發(fā)出兩份頁面出現(xiàn)兩段AI回復(fù)。這個問題排查了很久本質(zhì)是Effect cleanup里忘了調(diào)abort()。所以如果你用的是React 18記得把AbortController的清理動作放在useEffect的返回值里這是很多線上事故的隱藏元兇。流式數(shù)據(jù)本身并不復(fù)雜復(fù)雜的是在移動端這種資源受限的環(huán)境里把持續(xù)抵達(dá)的數(shù)據(jù)和有限的渲染能力調(diào)和好。這篇文章里講到的每一條經(jīng)驗(yàn)都是從真實(shí)項目中一行一行調(diào)試出來的希望可以幫你少走一些彎路。如果你在接入過程中遇到更奇怪的問題歡迎把你的現(xiàn)象和代碼片段分享出來我們一起來拆一拆。 H5 AI聊天流式響應(yīng)實(shí)戰(zhàn)：SSE解析、打字機(jī)渲染與性能優(yōu)化
1. 別急著接SDK先搞清楚H5里的AI流式響應(yīng)到底卡在哪做AI聊天功能很多前端朋友第一次接后端流式接口時都會遇到同一個困惑明明后端數(shù)據(jù)是一段一段吐出來的自己也用了EventSource或者fetch的ReadableStream頁面上的效果卻還是像憋大招——等好幾秒才一次性蹦出一整段文字中間沒有任何逐字出現(xiàn)的過程。我早先在給某模擬項目X做移動端H5客服助手時也踩過這個坑。后來把整個鏈路從網(wǎng)絡(luò)層、數(shù)據(jù)解析層到渲染層全捋了一遍才明白H5里處理AI聊天流式數(shù)據(jù)難點(diǎn)根本不在怎么拿到流而在拿到流之后怎么低成本地解析、按節(jié)奏渲染、并且在弱網(wǎng)和中途打斷時不讓體驗(yàn)崩掉。這篇文章不聊怎么調(diào)大模型API也不聊后端的SSE怎么發(fā)專注講前端H5這一側(cè)的事。內(nèi)容包括為什么response.body拿到的流不能被直接await完再處理流式數(shù)據(jù)解析時最容易做錯的TextDecoder用法打字機(jī)效果為什么不能簡單setInterval以及正確的節(jié)流方案用戶點(diǎn)擊停止生成后前端需要做哪些清理動作長文本高算量場景下怎么避免頁面卡頓、白屏、內(nèi)存暴漲弱網(wǎng)、異常中斷、半截JSON這些臟數(shù)據(jù)怎么兜底整體思路適合已經(jīng)會用fetch、了解Promise基礎(chǔ)的前端開發(fā)者如果你正在做AI對話類產(chǎn)品照著這篇文章可以少走不少彎路。2. 流式方案選型SSE與WebSocket別一上來就選WebSocket先講一個容易被帶偏的選型問題。很多人聽到流式就覺得必須上WebSocket實(shí)際上AI聊天場景大多數(shù)后端都提供的是SSEServer-Sent Events這是一種基于HTTP的推送協(xié)議服務(wù)端可以持續(xù)向客戶端發(fā)送數(shù)據(jù)直到主動斷開。2.1 為什么說SSE在AI聊天場景往往更合適從對話需求看AI聊天是用戶請求一次模型回復(fù)一次的單向長連接服務(wù)端向客戶端持續(xù)輸出內(nèi)容。SSE天生就是干這個的它復(fù)用HTTP協(xié)議不需要額外的握手協(xié)議而且有自動重連機(jī)制。實(shí)現(xiàn)起來也簡單后端不需要維護(hù)狀態(tài)化的連接池。舉個例子有次我接一個快速原型后端同事臨時用Node寫了兼容OpenAI格式的流式接口返回的是text/event-stream我用fetch就能直接消費(fèi)前后端聯(lián)調(diào)一共花了不到半小時。如果這時候換成WebSocket得處理連接建立、心跳?；?、消息編解碼明顯更重。WebSocket真正適合的是雙向高頻交互場景比如在線協(xié)作、多人同步、實(shí)時游戲互相發(fā)指令。聊天里大多數(shù)情況都是用戶發(fā)一句、AI回一段雙方并行的概率很低用WebSocket屬于殺雞用牛刀。所以如果后端已經(jīng)提供了SSE接口H5前端直接用就好。如果后端硬要WebSocket那就需要評估是否真的有雙向低延遲通信的需求沒有的話可以堅持一下SSE。2.2 用fetch消費(fèi)SSE流比EventSource好在哪瀏覽器原生有個EventSource只能做GET請求而且不能自定義請求頭。AI場景里常需要帶Token鑒權(quán)、傳用戶ID、指定模型參數(shù)這些用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可以持續(xù)讀取 return response.body.getReader() })這樣做的好處是請求方式、請求頭、超時控制、中斷信號全部都能自己掌握。缺點(diǎn)是需要自己解析SSE格式的數(shù)據(jù)但解析邏輯并不復(fù)雜下面會講。3. SSE數(shù)據(jù)流的完整處理鏈路從原始字節(jié)到UI文字拿到ReadableStream只是第一步接下來要做的核心事情有三個解碼字節(jié)、切分事件幀、解析JSON載荷。3.1 字節(jié)解碼必須用TextDecoder且要設(shè)置stream為trueReadableStream默認(rèn)輸出的是Uint8Array字節(jié)塊。如果直接用new TextDecoder().decode(chunk)在中文內(nèi)容里會出現(xiàn)亂碼因?yàn)橐粋€漢字通常是3個字節(jié)流式傳輸時可能把一個字的字節(jié)切到兩個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的字節(jié)被截斷 } // 最后一定要再調(diào)一次 decoder.decode()清空緩沖區(qū) const rest decoder.decode()TextDecoder加stream: true后會把沒湊完整的多字節(jié)字符緩存起來下一次decode時再拼接這樣切在任意位置的漢字都能正確還原。這是流式解析最容易踩的一個坑很多問為什么AI回答里偶爾出現(xiàn)一個亂碼字的問題根因就在這里。3.2 SSE事件幀的邊界切分SSE協(xié)議規(guī)定消息之間用空行\(zhòng)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直接丟棄等下一個塊繼續(xù) } } return events }注意兩點(diǎn)一是同一事件的數(shù)據(jù)行可能有多行需要拼起來再解析二是[DONE]這種結(jié)束標(biāo)記有些后端會發(fā)有些不發(fā)前端最好都能兼容。提示我在接入過程中發(fā)現(xiàn)不同的后端框架對SSE的格式實(shí)現(xiàn)略有差異。有的會在每條消息后發(fā)\r\n\r\n有的只發(fā)\n\n有的會把data:寫成data全角冒號這是后端bug。解析時最好統(tǒng)一做一下兼容處理比如把\r\n先替換成\n再按\n\n切分。3.3 增量內(nèi)容與最終消息的區(qū)分現(xiàn)在主流的大模型流式接口比如OpenAI兼容協(xié)議返回格式通常是choices[0].delta.content。delta是增量就是說每次事件里只有新增的幾個字。不過實(shí)際項目中有三種情況純增量模式每幀只有新增內(nèi)容前端直接追加渲染全量疊加模式每幀帶的是到當(dāng)前為止的完整內(nèi)容前端要整體替換兩者混合有的幀是增量有的幀是全量比如角色信息、工具調(diào)用我在處理某圖像處理Demo的對話日志時遇到過混用的情況。穩(wěn)妥做法是維護(hù)一個狀態(tài)字段判斷后端返回的是delta還是message分別走追加和替換邏輯。如果不做區(qū)分用戶會看到AI回答的同一段文字被反復(fù)重繪閃得厲害。4. 打字機(jī)渲染的正確姿勢從無腦追加到幀率控制的演進(jìn)流式數(shù)據(jù)解析出來了如果直接把每段文字appendChild或者textContent 在桌面端可能還好但H5頁面在手機(jī)上極容易卡頓。因?yàn)槊繋瑪?shù)據(jù)到達(dá)頻率可能高達(dá)每30ms一次而瀏覽器渲染一幀的時間一般是16.6ms全量重繪根本吃不消。更合理的方式是實(shí)現(xiàn)一個消息隊列 定時刷盤的渲染機(jī)制。4.1 數(shù)據(jù)到達(dá)頻率與渲染頻率解耦核心思路是把從網(wǎng)絡(luò)到達(dá)的數(shù)據(jù)推入一個緩沖區(qū)然后用requestAnimationFrame控制渲染節(jié)奏每幀只把緩沖區(qū)里攢下的內(nèi)容一次性渲染到頁面上。function createTypingStream(onContent) { let buffer let scheduled false function flush() { if (!buffer) { scheduled false return } const text buffer buffer scheduled false onContent(text) // 在這里把 content 追加到頁面節(jié)點(diǎn) } return { push(text) { buffer text if (!scheduled) { scheduled true requestAnimationFrame(flush) } }, end() { flush() } } }這樣做的好處在于即便后端一秒鐘推送了30個片段頁面也只會跟隨屏幕刷新率重繪頂多每秒60次。而且requestAnimationFrame在標(biāo)簽頁切到后臺時會自動暫停不會空耗性能。實(shí)際測試下來長對話頁面文字滾動順滑很多幀數(shù)從掉到20幀提升到穩(wěn)定55幀以上。4.2 不做防抖會帶來什么問題有朋友會問我直接用setTimeout防抖不行嗎其實(shí)也行但有一些小問題setTimeout的延遲時間如果設(shè)得太短比如50ms遇到高頻數(shù)據(jù)仍可能堆積如果設(shè)得太長比如300ms用戶能看到明顯的一頓一頓效果觀感變差頁面切換到后臺時setTimeout還是會跑不必要的計算仍然發(fā)生requestAnimationFrame則剛好跟著顯示器的節(jié)奏走而且切后臺自動暫停。唯一要注意的是它不一定每秒恰好60次有些高刷手機(jī)是90幀、120幀但這不影響使用因?yàn)榱魇轿谋咀芳颖緛聿恍枰獓?yán)格等間隔。4.3 快速滾動的處理聊天過程中用戶通常希望最新的文字自動出現(xiàn)在視口里這時需要控制滾動容器到底部。但如果每一幀都滾動一次連續(xù)滾動會帶來比較大的性能開銷而且有可能打斷用戶正在往上翻看歷史記錄的操作。我的做法是記錄用戶是否在視口底部只有用戶停留在底部時才執(zhí)行滾動。如果用戶上翻查看歷史內(nèi)容自動滾動立即停止。function scrollToBottomIfNeeded(container) { const distance container.scrollHeight - container.scrollTop - container.clientHeight if (distance 24) { container.scrollTop container.scrollHeight } }這個距離底部小于24px才滾動的閾值是我試出來的個人經(jīng)驗(yàn)值不同設(shè)計可以微調(diào)。核心目的是避免不分情況強(qiáng)制滾動造成的糟糕體驗(yàn)。5. 流式對話中停止生成按鈕從信號傳遞到資源回收的完整鏈路AI流式對話的一個剛需功能是用戶覺得AI答得太啰嗦、方向不對點(diǎn)一下停止請求立刻中斷后面沒吐完的內(nèi)容全部丟棄頁面停留在已有文字上。5.1 AbortController的正確用法fetch支持通過AbortController中斷請求。比較穩(wěn)妥的做法是將controller存到組件的實(shí)例或者一個全局管理Map里點(diǎn)擊停止時調(diào)用abortconst controller new AbortController() fetch(/api/chat/stream, { signal: controller.signal, }) // 停止生成 function stopGenerate() { controller.abort() }有個細(xì)節(jié)是abort之后reader.read()會拋出一個AbortError的DOMException需要在循環(huán)里捕獲并當(dāng)作正常結(jié)束來處理而不是把它傳到全局錯誤處理。while (true) { try { const { value, done } await reader.read() if (done) break // 處理數(shù)據(jù) } catch (err) { if (err.name AbortError) { break // 用戶主動中斷正常結(jié)束 } throw err } }5.2 中斷后的狀態(tài)清理中斷不能只停留在請求斷了界面上還有幾件事要同步處理把停止生成按鈕隱藏/禁用恢復(fù)可以輸入的狀態(tài)如果有加載動畫、光標(biāo)閃爍動畫要停掉當(dāng)前AI消息的正在生成標(biāo)記要置為完成如果有聲音提示、震動反饋也要在這里處理我在模擬項目X里用過一個簡單的狀態(tài)機(jī)idle-streaming-done/aborted。任何狀態(tài)下點(diǎn)停止都只允許從streaming流轉(zhuǎn)到aborted避免連點(diǎn)兩次造成重復(fù)的abort操作。5.3 結(jié)束標(biāo)記的處理不能依賴[DONE]前面提過不同的后端實(shí)現(xiàn)里流結(jié)束的標(biāo)記不同。有的會發(fā)一行data: [DONE]有的會在傳輸完畢后正常關(guān)閉流done為true還有的會直接斷開連接導(dǎo)致瀏覽器出現(xiàn)網(wǎng)絡(luò)錯誤。所以不能把[DONE]當(dāng)作唯一的結(jié)束判定。我在實(shí)現(xiàn)里是同時監(jiān)聽兩個信號parser是否收到[DONE]reader是否返回done: true兩者只要有一個觸發(fā)都進(jìn)入結(jié)束流程。另外還要設(shè)置一個兜底的超時時間比如60秒無數(shù)據(jù)自動結(jié)束或者報錯避免后端進(jìn)程掛死、連接半開不閉導(dǎo)致的永遠(yuǎn)加載中。6. 長文本渲染性能從DOM追加到虛擬滾動與CSS處理AI聊天很容易出現(xiàn)幾千字的長回復(fù)尤其在H5里連續(xù)把幾千字全部渲染進(jìn)頁面會出現(xiàn)卡頓和內(nèi)存占用暴漲。這不是React或Vue的錯根源是瀏覽器在渲染大文本、重排長列表時的天然開銷。6.1 消息節(jié)點(diǎn)不要無腦重建很多框架寫法是setState({ text: currentText })每次流式內(nèi)容更新都把整個消息組件重新渲染。高頻更新下組件Diff和DOM重建開銷巨大在低端安卓機(jī)上會非常明顯。一個比較實(shí)用的優(yōu)化是把消息拆成外殼節(jié)點(diǎn)和內(nèi)容節(jié)點(diǎn)外殼不隨內(nèi)容頻繁變更內(nèi)容節(jié)點(diǎn)只更新自己的textContent。如果用的是原生DOM操作直接對現(xiàn)有節(jié)點(diǎn)做textContent增量追加跳過內(nèi)層模板渲染。如果是Vue/React可以用v-html直接操作已存在節(jié)點(diǎn)但要非常注意XSS風(fēng)險AI內(nèi)容不確定來源不建議直接v-html。我實(shí)際比較推薦的做法是要顯示的文本在進(jìn)入渲染前做一次純文本化處理把、轉(zhuǎn)義代碼塊內(nèi)容轉(zhuǎn)成受控的富文本節(jié)點(diǎn)。這樣既避免XSS也避免每次更新時全量解析HTML導(dǎo)致的性能問題。6.2 虛擬滾動不是第一優(yōu)先級的方案有人會說幾千字文本為什么不直接上虛擬滾動我的經(jīng)驗(yàn)是虛擬滾動對很多條短消息的場景價值大對一條超長消息的場景價值反而有限。因?yàn)樗獙?shí)時計算每個節(jié)點(diǎn)的高度而流式文本高度在動態(tài)變化中虛擬列表很容易頻繁觸發(fā)重算復(fù)雜度很高。如果真遇到超長文本更簡單的做法是對單條消息的內(nèi)容做折疊/展開處理超過一定字?jǐn)?shù)自動折疊把代碼塊、長JSON等獨(dú)立節(jié)點(diǎn)懶渲染滾動到可視區(qū)附近再填充內(nèi)容6.3 文本節(jié)點(diǎn)拆分與樣式隔離流式文本如果包含Markdown比較穩(wěn)妥的做法是分塊渲染先渲染純文本按照markdown規(guī)則解析的節(jié)點(diǎn)再對代碼塊等特殊部分單獨(dú)處理。流式更新時如果每次都重新解析全文在長文本下代價很大。我的一個優(yōu)化技巧是解析器按一定規(guī)則將內(nèi)容切分成純文本段落和特殊塊代碼/表格/公式每次增量到達(dá)只更新最后一個未閉合的段落塊已閉合的段落塊不再重新解析。這讓長文本流式解析的CPU占用下降了將近一半。7. 弱網(wǎng)、半截JSON與異常中斷的兜底策略真實(shí)線上環(huán)境比調(diào)試環(huán)境復(fù)雜得多弱網(wǎng)、代理超時、后端重啟、進(jìn)程OOM都會把好好的SSE流搞得亂七八糟。處理流式數(shù)據(jù)時以下問題要提前想到。7.1 半截JSON的容錯前面解析SSE時提到半截JSON要直接丟棄。但有一種情況是一個SSE事件本身沒傳完連接就斷了解析器在下一輪才收到剩余字節(jié)。這時不能讓解析狀態(tài)錯亂。做法是引入一個pendingText變量把每次decode出來的字符串先和之前的殘留拼到一起再做分塊解析。解析不掉的尾巴繼續(xù)留給下一輪。如果連接最終中斷殘留在緩沖區(qū)里的數(shù)據(jù)直接清空不回顯給用戶。7.2 自動重連與續(xù)傳的取舍有些場景希望斷網(wǎng)后自動重連并繼續(xù)生成。這對AI對話來說會比較麻煩因?yàn)楹蠖舜竽Ｐ偷臓顟B(tài)可能已經(jīng)丟失重連后重新發(fā)起請求可能會重復(fù)生成。所以在對話場景里我通常選擇不自動續(xù)傳、只提示用戶可重新發(fā)送反而更簡單穩(wěn)妥。如果你的產(chǎn)品確實(shí)需要斷線續(xù)傳比如長文檔生成那得前后端配合前端記錄已渲染文本的字符數(shù)后端支持從指定偏移量恢復(fù)。這一個功能設(shè)計量不小前端側(cè)只能作為輔助。7.3 半程無數(shù)據(jù)時的超時與心跳SSE連接建立后如果長時間沒有任何數(shù)據(jù)到達(dá)要區(qū)分是模型在思考還是連接已死。最直接的方法記錄最后一條數(shù)據(jù)到達(dá)的時間每5秒檢查一次。如果超過閾值無數(shù)據(jù)先嘗試發(fā)一個ping到后端仍無響應(yīng)則判定超時。閾值我習(xí)慣設(shè)為30秒因?yàn)槟承┐竽Ｐ退伎紩r間確實(shí)較長但一般不會超過這個值。setInterval(() { if (Date.now() - lastDataTime 30000) { controller.abort() showError(響應(yīng)超時請稍后重試) } }, 5000)注意這個定時器在消息完成后記得清除不然頁面停留也會一直跑。7.4 后端報錯與半程HTTP狀態(tài)碼SSE流有個特點(diǎn)HTTP狀態(tài)碼通常是在連接建立時就返回了200后續(xù)的錯誤只能靠流內(nèi)部傳遞。但有一種情況是網(wǎng)關(guān)層在流式傳輸中途返回錯誤比如401過期這時response.body可能正常但后續(xù)沒有數(shù)據(jù)。前端一定要監(jiān)聽兩個點(diǎn)response.ok為false時直接走錯誤處理不要嘗試讀流流讀取過程中reader.read()拋出異常要區(qū)分是網(wǎng)絡(luò)錯誤還是協(xié)議錯誤分別展示不同的提示文案注意在H5弱網(wǎng)場景里有時read()會拋TypeError: Failed to fetch這種錯誤通常不是后端邏輯問題而是網(wǎng)關(guān)或?yàn)g覽器層斷連。提示用戶網(wǎng)絡(luò)連接不穩(wěn)定比服務(wù)器錯誤更準(zhǔn)確也更友好。8. 關(guān)于狀態(tài)管理、并發(fā)對話與緩存去重聊完底層最后串一下上層設(shè)計。8.1 并發(fā)對話的管理有些AI產(chǎn)品允許同時開多個對話窗口此時如果用戶快速切換舊的流式請求還在跑新窗口又發(fā)起請求容易出現(xiàn)狀態(tài)串臺。我建議維護(hù)一個Mapkey是會話IDvalue是AbortController。切走會話時通知用戶生成仍在繼續(xù)切回時數(shù)據(jù)還在累積如果用戶關(guān)閉會話則直接abort回收。8.2 消息滾動的去重流式追加時偶爾會出現(xiàn)重復(fù)內(nèi)容。原因可能是后端重試、網(wǎng)關(guān)重發(fā)或者前端在重連后重復(fù)處理了同一事件。前端可以在追加時做一個簡單校驗(yàn)記錄已渲染的末尾字符與新內(nèi)容的前綴做比對若重復(fù)則截斷重復(fù)部分再追加。這個邏輯成本極低卻能在一些異常場景里顯著減少內(nèi)容重復(fù)兩遍的體驗(yàn)問題。8.3 響應(yīng)內(nèi)容的展示順序有些AI會先輸出思考過程再輸出正文或者穿插引用、工具調(diào)用信息。流式情況下如果后端把不同類型的數(shù)據(jù)混在同一個流里前端要做的是按類型分發(fā)到不同容器避免思考和正文混在一起顯示。我在處理某跨平臺系統(tǒng)的日志分析功能時把類型字段放到事件解析的分發(fā)層效率比在UI層反復(fù)判斷高得多。9. 實(shí)測下來的性能參考與經(jīng)驗(yàn)總結(jié)最后給一個真實(shí)的項目參考數(shù)據(jù)方便大家心里有底。我在某模擬項目X里做了兩次優(yōu)化前后的對比指標(biāo)優(yōu)化前無緩沖直接渲染優(yōu)化后RAF緩沖渲染低端安卓機(jī)渲染幀率20~30幀滾動明顯卡頓55~60幀跟手順滑3000字長回復(fù)渲染耗時約3.8秒約1.9秒頁面內(nèi)存峰值約460MB約290MBCPU持續(xù)占用60%~80%30%~45%每一項優(yōu)化帶來的收益都挺直觀。當(dāng)然不同機(jī)型、不同瀏覽器有差異但方向是一致的流式數(shù)據(jù)的處理核心永遠(yuǎn)是減少不必要的工作量把網(wǎng)絡(luò)到達(dá)的頻率和UI渲染的頻率解耦把解析和渲染分開把異常中斷當(dāng)成正常流程來處理。如果讓我給剛接觸AI流式聊天的新手一個最直接的行動建議那就是先把TextDecoder和requestAnimationFrame兩個點(diǎn)吃透再談其它。前者解決字對不對的問題后者解決卡不卡的問題。這兩個點(diǎn)做到位H5里的AI聊天體驗(yàn)基本就合格了一大半。我自己在最初幾次調(diào)試時還踩過一個比較隱蔽的坑在React StrictMode下組件會渲染兩次如果副作用沒有清理干凈同一個流式請求會發(fā)出兩份頁面出現(xiàn)兩段AI回復(fù)。這個問題排查了很久本質(zhì)是Effect cleanup里忘了調(diào)abort()。所以如果你用的是React 18記得把AbortController的清理動作放在useEffect的返回值里這是很多線上事故的隱藏元兇。流式數(shù)據(jù)本身并不復(fù)雜復(fù)雜的是在移動端這種資源受限的環(huán)境里把持續(xù)抵達(dá)的數(shù)據(jù)和有限的渲染能力調(diào)和好。這篇文章里講到的每一條經(jīng)驗(yàn)都是從真實(shí)項目中一行一行調(diào)試出來的希望可以幫你少走一些彎路。如果你在接入過程中遇到更奇怪的問題歡迎把你的現(xiàn)象和代碼片段分享出來我們一起來拆一拆。