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