1. 從逐字蹦出的觀感說起打字機(jī)效果到底難在哪第一次做 AI 對(duì)話界面的人幾乎都會(huì)卡在同一個(gè)地方后端明明已經(jīng)把整段回答生成好了前端卻只能等全部?jī)?nèi)容返回后一次性渲染出來用戶盯著空白屏幕轉(zhuǎn)圈十幾秒體驗(yàn)非常糟糕。而市面上那些成熟的對(duì)話產(chǎn)品回答是一個(gè)字一個(gè)字往外蹦的像老式打字機(jī)一樣這種觀感背后其實(shí)是一整套從傳輸協(xié)議到渲染層的配合。我最早做這塊的時(shí)候也走過彎路一開始想的是前端定時(shí)器模擬把整段文本切片后按固定間隔塞進(jìn) DOM。這個(gè)方案在演示階段看著還行真上線就露餡了模型生成速度是不均勻的遇到長(zhǎng)回答時(shí)前端演的速度和真實(shí)生成速度對(duì)不上用戶刷新頁面就全丟了而且首字延遲一點(diǎn)沒改善。后來才轉(zhuǎn)向真正的流式方案也就是讓數(shù)據(jù)在生成過程中就持續(xù)推給前端。這套東西拆開來看是三層傳輸層負(fù)責(zé)把服務(wù)端生成的內(nèi)容實(shí)時(shí)送到瀏覽器主流做法是 SSE渲染層負(fù)責(zé)把不斷追加的 Markdown 文本正確顯示出來涉及增量解析和未閉合標(biāo)簽處理網(wǎng)關(guān)層負(fù)責(zé)讓流式數(shù)據(jù)穿過 Nginx 這類反向代理時(shí)不被緩沖、不被超時(shí)切斷。三層里任何一層出問題用戶看到的就是卡住不動(dòng)或者內(nèi)容粘連成一坨。這篇文章面向的是正在做或準(zhǔn)備做 AI 對(duì)話界面的開發(fā)者不管你用的是 Vue、React 還是原生 JS不管你后端是 Java、Python 還是 Node這套思路都是通用的。我會(huì)把 SSE 的協(xié)議細(xì)節(jié)、Markdown 增量渲染的坑、Nginx 的關(guān)鍵配置逐層拆開講并且給出可以直接抄的配置和代碼。讀完你應(yīng)該能獨(dú)立搭出一套穩(wěn)定的流式對(duì)話鏈路并且知道每個(gè)參數(shù)為什么這么設(shè)。2. SSE 流式傳輸為什么是它而不是 WebSocket 或輪詢2.1 三種方案的取舍邏輯做流式推送擺在面前的選擇其實(shí)就三個(gè)短輪詢、WebSocket、SSE。短輪詢是最笨但最省事的前端每隔一秒發(fā)一次請(qǐng)求問生成完了嗎服務(wù)端返回當(dāng)前進(jìn)度。它的致命問題是延遲和資源浪費(fèi)一秒的間隔意味著首字延遲至少一秒而且每次請(qǐng)求都要重新建立連接、攜帶完整上下文服務(wù)端壓力隨用戶數(shù)線性上漲。我實(shí)測(cè)過一個(gè)兩百人同時(shí)在線的場(chǎng)景輪詢方案下 QPS 直接飆到四百多純屬浪費(fèi)。WebSocket 是雙向全雙工能力最強(qiáng)但它對(duì) AI 對(duì)話來說屬于殺雞用牛刀。對(duì)話場(chǎng)景的數(shù)據(jù)流向是單向的服務(wù)端推、客戶端收。用 WebSocket 你得自己定義消息格式、自己做心跳?；睢⒆约禾幚碇剡B而且很多網(wǎng)關(guān)和負(fù)載均衡對(duì) WebSocket 的支持需要額外配置。更麻煩的是WebSocket 連接是有狀態(tài)的水平擴(kuò)展時(shí)需要考慮會(huì)話粘滯運(yùn)維復(fù)雜度上一個(gè)臺(tái)階。SSE 恰好卡在中間它基于普通 HTTP單向服務(wù)端推送瀏覽器原生支持EventSource斷線自動(dòng)重連穿過 Nginx 只需要改幾個(gè)配置。對(duì)于服務(wù)端持續(xù)推文本給前端這個(gè)需求它是成本最低、最貼合的選擇。這也是為什么主流大模型 API 的流式接口幾乎清一色用 SSE。方案首字延遲服務(wù)端壓力雙向能力網(wǎng)關(guān)友好度適用場(chǎng)景短輪詢高等于輪詢間隔高無極好兼容性兜底WebSocket低低強(qiáng)一般雙向?qū)崟r(shí)交互SSE低低單向好服務(wù)端單向推送2.2 SSE 協(xié)議格式那些必須記死的細(xì)節(jié)SSE 的報(bào)文格式看著簡(jiǎn)單但有幾個(gè)細(xì)節(jié)不搞清楚就會(huì)踩坑。它的響應(yīng)頭必須是Content-Type: text/event-stream并且要帶上Cache-Control: no-cache和Connection: keep-alive。數(shù)據(jù)體的格式是純文本每條消息由若干字段行組成字段和值之間用冒號(hào)加空格分隔消息之間用空行分隔。data: 你好 data: 世界 data: 第二段消息上面這段里第一個(gè)消息塊的兩行data會(huì)被拼接成你好\n世界然后遇到空行觸發(fā)一次message事件。注意data:后面如果只有一個(gè)空格那個(gè)空格是分隔符不算內(nèi)容如果內(nèi)容本身以空格開頭需要寫兩個(gè)空格。這個(gè)細(xì)節(jié)很多人第一次寫會(huì)搞錯(cuò)導(dǎo)致輸出莫名其妙多一個(gè)空格。除了data還有幾個(gè)字段值得知道event用來指定事件類型默認(rèn)是messageid用來標(biāo)記消息序號(hào)斷線重連時(shí)瀏覽器會(huì)通過Last-Event-ID請(qǐng)求頭帶上最后收到的 id服務(wù)端可以據(jù)此續(xù)傳retry用來指定重連間隔毫秒數(shù)。對(duì)于 AI 對(duì)話id字段其實(shí)很有用配合服務(wù)端的會(huì)話狀態(tài)可以實(shí)現(xiàn)斷點(diǎn)續(xù)傳不過大多數(shù)場(chǎng)景下前端直接重新發(fā)起一次請(qǐng)求更簡(jiǎn)單。2.3 為什么原生 EventSource 常常不夠用瀏覽器原生的EventSource用起來很省心但它有兩個(gè)硬傷。第一它只支持 GET 請(qǐng)求沒法帶請(qǐng)求體。AI 對(duì)話的 prompt 往往很長(zhǎng)塞進(jìn) URL 查詢參數(shù)既不優(yōu)雅也可能超長(zhǎng)。第二它不能自定義請(qǐng)求頭沒法帶認(rèn)證 token只能靠 Cookie 或者把 token 塞 URL 里安全性差。所以實(shí)際項(xiàng)目里更常見的是用fetch配合ReadableStream手動(dòng)解析 SSE或者用microsoft/fetch-event-source這個(gè)庫。后者封裝了重連、事件解析、AbortController 取消等邏輯用起來比手寫省心。手寫的話核心就是拿到response.body.getReader()然后循環(huán)read()把拿到的Uint8Array用TextDecoder解碼再按\n\n切分消息塊。async function streamChat(prompt, onChunk, signal) { const resp await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ prompt, stream: true }), signal }); const reader resp.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const parts buffer.split(\n\n); buffer parts.pop(); // 最后一段可能不完整留到下次 for (const part of parts) { const line part.trim(); if (!line.startsWith(data:)) continue; const payload line.slice(5).trim(); if (payload [DONE]) return; onChunk(payload); } } }這里有個(gè)關(guān)鍵點(diǎn)decoder.decode(value, { stream: true })的stream: true參數(shù)不能省。因?yàn)橐粋€(gè) UTF-8 中文字符占三個(gè)字節(jié)網(wǎng)絡(luò)分片很可能把一個(gè)字符切成兩半不加這個(gè)參數(shù)就會(huì)解碼出亂碼。同理buffer的保留邏輯也不能省因?yàn)橐粋€(gè) SSE 消息塊可能被網(wǎng)絡(luò)分片切斷必須等下一片到了再拼起來解析。提示判斷流結(jié)束不要只看done很多服務(wù)端會(huì)在最后發(fā)一條data: [DONE]作為結(jié)束標(biāo)記前端收到后應(yīng)主動(dòng)關(guān)閉連接避免連接懸掛。3. Markdown 增量渲染未閉合標(biāo)簽才是真正的坑3.1 為什么不能每來一段就整體重渲染最樸素的做法是每收到一個(gè) chunk就把累積的全文丟給 Markdown 解析器重新渲染一遍。這個(gè)方案在短回答下沒問題但回答一長(zhǎng)就崩了。假設(shè)回答最終有 3000 字分 300 個(gè) chunk 到達(dá)那么總解析量是 12...300 個(gè) chunk 的文本量接近 45000 個(gè) chunk 的解析開銷而且每次都要重建整個(gè) DOM瀏覽器主線程會(huì)被打滿滾動(dòng)會(huì)卡頓輸入框會(huì)掉幀。正確的做法是增量渲染已經(jīng)渲染完成的部分不再動(dòng)只處理新增的內(nèi)容。但這里有個(gè)矛盾Markdown 是上下文相關(guān)的語法一個(gè)**加粗標(biāo)記可能跨 chunk一個(gè)代碼塊可能剛開始還沒閉合你不能簡(jiǎn)單地把新 chunk 直接 append 到 DOM 里。我的處理策略是分段提交維護(hù)一個(gè)未提交緩沖區(qū)每次新內(nèi)容進(jìn)來后追加到緩沖區(qū)然后嘗試解析。解析時(shí)只把確定完整的部分提交到已渲染區(qū)剩下的留在緩沖區(qū)等下次。判斷確定完整的規(guī)則是以空行段落邊界為切分點(diǎn)最后一個(gè)空行之前的內(nèi)容視為完整段落可以提交最后一個(gè)空行之后的內(nèi)容留在緩沖區(qū)。3.2 未閉合語法的處理清單即便按段落切分仍然會(huì)遇到各種未閉合的情況。下面這張表是我在實(shí)際項(xiàng)目里總結(jié)的常見場(chǎng)景和處理方式。未閉合場(chǎng)景表現(xiàn)處理方式加粗**只出現(xiàn)一個(gè)后續(xù)文字全變粗緩沖區(qū)檢測(cè)到奇數(shù)個(gè)**則不提交該段行內(nèi)代碼未閉合后續(xù)文字變代碼樣式同上檢測(cè)反引號(hào)配對(duì)代碼塊 未閉合后續(xù)全部進(jìn)代碼塊檢測(cè) 出現(xiàn)次數(shù)奇數(shù)則整段掛起鏈接[text](未閉合顯示原始文本檢測(cè)括號(hào)配對(duì)未閉合則掛起表格分隔行未到表格渲染成普通文本檢測(cè)到 列表項(xiàng)跨 chunk列表斷裂以空行為界列表項(xiàng)通常在同一段內(nèi)代碼塊是最麻煩的因?yàn)樗膬?nèi)容可能很長(zhǎng)如果一直等閉合用戶會(huì)看到代碼區(qū)遲遲不出現(xiàn)。我的做法是檢測(cè)到 開始后即使未閉合也先渲染成一個(gè)代碼塊容器只是標(biāo)記為進(jìn)行中等閉合后再補(bǔ)上語言高亮。這樣用戶至少能看到代碼在逐行出現(xiàn)而不是一片空白。3.3 一個(gè)可用的增量渲染實(shí)現(xiàn)下面這段邏輯是我在 Vue 項(xiàng)目里用的簡(jiǎn)化版核心思路是緩沖區(qū) 完整性檢測(cè) 分段提交。class MarkdownStreamRenderer { constructor(container) { this.container container; this.committed ; // 已提交渲染的文本 this.buffer ; // 待提交緩沖區(qū) } push(chunk) { this.buffer chunk; const { safe, rest } this.splitSafe(this.buffer); if (safe) { this.committed safe; this.buffer rest; this.render(); } } // 找到最后一個(gè)可安全提交的邊界 splitSafe(text) { // 優(yōu)先以空行切分 const idx text.lastIndexOf(\n\n); if (idx -1) return { safe: , rest: text }; const candidate text.slice(0, idx 2); const rest text.slice(idx 2); // 檢查候選區(qū)是否有未閉合語法 if (this.hasUnclosed(candidate)) { return { safe: , rest: text }; } return { safe: candidate, rest }; } hasUnclosed(text) { const fences (text.match(//g) || []).length; if (fences % 2 ! 0) return true; const bolds (text.match(/\*\*/g) || []).length; if (bolds % 2 ! 0) return true; return false; } render() { // 已提交部分整體渲染緩沖區(qū)部分作為預(yù)覽追加 this.container.innerHTML marked.parse(this.committed) (this.buffer ? div classstreaming${escapeHtml(this.buffer)}/div : ); } }這個(gè)實(shí)現(xiàn)有個(gè)取舍已提交部分每次都是整體重渲染。如果回答特別長(zhǎng)比如上萬字整體重渲染仍然有開銷。進(jìn)一步優(yōu)化可以只渲染新增的 safe 部分并 append 到容器但那樣需要處理跨段落的列表、引用等結(jié)構(gòu)復(fù)雜度會(huì)上升。對(duì)于絕大多數(shù)對(duì)話場(chǎng)景回答長(zhǎng)度在幾千字以內(nèi)整體重渲染完全夠用實(shí)測(cè)下來很穩(wěn)。注意緩沖區(qū)里的內(nèi)容用escapeHtml轉(zhuǎn)義后顯示不要直接丟給 Markdown 解析器否則未閉合的語法會(huì)污染整個(gè)渲染結(jié)果。3.4 換行和空格的顯示問題Markdown 有個(gè)反直覺的規(guī)則單個(gè)換行符在渲染時(shí)會(huì)被當(dāng)成空格只有空行才產(chǎn)生新段落。但 AI 生成的文本經(jīng)常用單換行來分行比如列舉要點(diǎn)時(shí)。如果嚴(yán)格按標(biāo)準(zhǔn) Markdown 渲染用戶看到的會(huì)是一大坨擠在一起的文字。解決辦法是開啟軟換行轉(zhuǎn)硬換行也就是把單個(gè)\n渲染成br。marked有breaks: true選項(xiàng)markdown-it有breaks: true開啟后單換行就會(huì)斷行。這個(gè)選項(xiàng)對(duì) AI 對(duì)話場(chǎng)景幾乎是必開的否則排版會(huì)很難看。但要注意開了之后代碼塊內(nèi)的換行不受影響因?yàn)榇a塊是獨(dú)立解析的。另一個(gè)常見問題是連續(xù)空格被折疊。HTML 默認(rèn)會(huì)把多個(gè)空格合并成一個(gè)如果 AI 輸出里有對(duì)齊用的空格比如 ASCII 圖就會(huì)錯(cuò)位。這種情況需要用white-space: pre-wrap或者把內(nèi)容包在代碼塊里。我的經(jīng)驗(yàn)是凡是涉及對(duì)齊的內(nèi)容都建議 AI 用代碼塊輸出前端就不用操心了。4. Nginx 反向代理流式數(shù)據(jù)為什么會(huì)被粘住4.1 緩沖才是流式最大的敵人本地開發(fā)時(shí)流式效果好好的一部署到線上就變成等半天然后一次性全出來十有八九是 Nginx 的緩沖在作怪。Nginx 作為反向代理默認(rèn)會(huì)把上游響應(yīng)先緩沖到自己的緩沖區(qū)攢夠一定大小或者上游關(guān)閉連接后才轉(zhuǎn)發(fā)給客戶端。這個(gè)設(shè)計(jì)對(duì)普通請(qǐng)求是優(yōu)化對(duì) SSE 就是災(zāi)難因?yàn)?SSE 的特點(diǎn)就是小包、持續(xù)、長(zhǎng)時(shí)間不關(guān)閉正好觸發(fā)緩沖。要關(guān)掉緩沖核心是proxy_buffering off。但光這一條還不夠還有幾個(gè)相關(guān)配置需要一起改。下面是我在生產(chǎn)環(huán)境用的配置片段。location /api/chat { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 關(guān)閉緩沖讓數(shù)據(jù)實(shí)時(shí)透?jìng)?proxy_buffering off; proxy_cache off; chunked_transfer_encoding on; # 關(guān)閉分塊響應(yīng)緩沖 proxy_set_header X-Accel-Buffering no; # 超時(shí)設(shè)置SSE 連接可能持續(xù)很久 proxy_read_timeout 300s; proxy_send_timeout 300s; proxy_connect_timeout 60s; }逐條解釋一下為什么這么設(shè)。proxy_http_version 1.1是必須的因?yàn)?HTTP/1.0 不支持分塊傳輸SSE 就沒法流式。proxy_set_header Connection 是為了清掉默認(rèn)的Connection: close保持長(zhǎng)連接。proxy_buffering off是核心關(guān)掉響應(yīng)緩沖。X-Accel-Buffering no這個(gè)響應(yīng)頭是給 Nginx 看的即使全局開了緩沖這個(gè)頭也能讓 Nginx 對(duì)當(dāng)前響應(yīng)禁用緩沖雙保險(xiǎn)。4.2 超時(shí)參數(shù)那個(gè)讓人抓狂的 idle timeout熱詞里有個(gè)報(bào)錯(cuò)很典型stream disconnected before completion: idle timeout waiting for sse。這個(gè)錯(cuò)誤的根源就是超時(shí)。SSE 連接建立后如果模型思考時(shí)間較長(zhǎng)比如推理模型要思考十幾秒這段時(shí)間內(nèi)沒有數(shù)據(jù)推送Nginx 的proxy_read_timeout一到就會(huì)切斷連接前端就報(bào)這個(gè)錯(cuò)。proxy_read_timeout默認(rèn)是 60 秒對(duì)于普通請(qǐng)求夠用對(duì)于 SSE 太短。我一般設(shè)成 300 秒甚至更長(zhǎng)具體看業(yè)務(wù)場(chǎng)景。但要注意這個(gè)值不能無限大因?yàn)槿绻蛻舳水惓嚅_而服務(wù)端沒感知連接會(huì)一直掛著占資源。合理的做法是配合心跳服務(wù)端每隔 15 到 30 秒發(fā)一個(gè)注釋行以冒號(hào)開頭的行如: keepalive既能讓 Nginx 知道連接活躍也能讓前端知道連接沒斷。# 全局或 server 塊中 proxy_read_timeout 300s; proxy_send_timeout 300s; # 如果用了 upstream還要注意 keepalive upstream backend { server 127.0.0.1:8080; keepalive 32; }心跳這個(gè)機(jī)制值得單獨(dú)說。SSE 協(xié)議里以冒號(hào)開頭的行是注釋會(huì)被瀏覽器忽略但會(huì)重置超時(shí)計(jì)時(shí)器。所以服務(wù)端在等待模型輸出的間隙定時(shí)發(fā)一個(gè):\n\n就能有效防止 idle timeout。這個(gè)技巧在推理模型場(chǎng)景下幾乎是必備的因?yàn)橥评砟Ｐ偷乃伎茧A段可能長(zhǎng)達(dá)幾十秒沒有任何輸出。4.3 負(fù)載均衡和壓縮的坑如果后端是多實(shí)例部署前面掛了負(fù)載均衡SSE 會(huì)遇到會(huì)話粘滯問題。因?yàn)橐淮螌?duì)話的流式響應(yīng)必須由同一個(gè)后端實(shí)例處理如果請(qǐng)求被輪詢到不同實(shí)例上下文就對(duì)不上了。解決辦法是在負(fù)載均衡層配置基于 Cookie 或者基于客戶端 IP 的粘滯會(huì)話。Nginx 的ip_hash是最簡(jiǎn)單的方案但在 NAT 環(huán)境下會(huì)導(dǎo)致負(fù)載不均更好的做法是用sticky模塊或者在上層用一致性哈希。另一個(gè)坑是 gzip 壓縮。Nginx 默認(rèn)可能對(duì)text/event-stream開啟 gzip壓縮會(huì)引入緩沖破壞流式效果。雖然text/event-stream通常不在默認(rèn)的 gzip 類型列表里但如果你手動(dòng)配了gzip_types包含它就要小心。我的建議是明確排除或者在 SSE 的 location 里直接gzip off。location /api/chat { gzip off; # ... 其他配置 }還有proxy_request_buffering這個(gè)是緩沖請(qǐng)求體的對(duì) SSE 響應(yīng)沒影響但如果你的 prompt 很大關(guān)掉它可以減少首字延遲。不過關(guān)掉后請(qǐng)求體會(huì)直接透?jìng)鹘o后端后端要能處理流式請(qǐng)求體一般場(chǎng)景下保持默認(rèn)即可。5. 前后端配合的完整鏈路與實(shí)測(cè)經(jīng)驗(yàn)5.1 服務(wù)端怎么把內(nèi)容推出來后端這塊不同語言的寫法差異很大但核心都是拿到模型返回的流逐塊轉(zhuǎn)發(fā)給客戶端。以 Java 為例如果用 Spring 的SseEmitter要注意它默認(rèn)會(huì)在一個(gè)線程里同步發(fā)送如果模型返回慢會(huì)阻塞。更好的做法是用WebFlux的FluxServerSentEvent天然支持背壓和異步。Python 的話FastAPI 的StreamingResponse配合生成器函數(shù)是最順手的。關(guān)鍵點(diǎn)是生成器里要yield出符合 SSE 格式的字符串并且設(shè)置正確的響應(yīng)頭。from fastapi import FastAPI from fastapi.responses import StreamingResponse app FastAPI() async def event_generator(prompt: str): async for chunk in call_llm_stream(prompt): # 注意chunk 里如果有換行要拆成多個(gè) data 行 for line in chunk.split(\n): yield fdata: {line}\n yield \n yield data: [DONE]\n\n app.post(/api/chat) async def chat(prompt: str): return StreamingResponse( event_generator(prompt), media_typetext/event-stream, headers{ Cache-Control: no-cache, X-Accel-Buffering: no, } )這里有個(gè)細(xì)節(jié)如果 chunk 內(nèi)容里包含換行符直接yield fdata: {chunk}\n\n會(huì)導(dǎo)致 SSE 解析錯(cuò)亂因?yàn)閾Q行會(huì)被當(dāng)成消息分隔。正確做法是把內(nèi)容里的換行拆開每行單獨(dú)加data:前綴。上面代碼里的for line in chunk.split(\n)就是干這個(gè)的。5.2 前端渲染的性能優(yōu)化前端這塊除了前面說的增量渲染還有幾個(gè)性能點(diǎn)值得注意。第一是滾動(dòng)跟隨新內(nèi)容進(jìn)來時(shí)如果用戶沒有手動(dòng)上滑應(yīng)該自動(dòng)滾到底部如果用戶上滑了就不要強(qiáng)制拉回否則用戶沒法回看。判斷邏輯是檢測(cè)滾動(dòng)條是否在底部附近比如距底部小于 50px。第二是節(jié)流渲染如果 chunk 到達(dá)頻率很高比如每秒幾十個(gè)每個(gè) chunk 都觸發(fā)一次渲染會(huì)導(dǎo)致頻繁重排?？梢杂胷equestAnimationFrame做節(jié)流把一幀內(nèi)的多個(gè) chunk 合并成一次渲染。let pending false; function scheduleRender() { if (pending) return; pending true; requestAnimationFrame(() { renderer.render(); pending false; }); }第三是代碼高亮的延遲代碼塊在流式過程中不斷變化如果每次都重新高亮開銷很大。我的做法是流式過程中代碼塊用純文本顯示等整個(gè)回答結(jié)束后再統(tǒng)一做一次高亮。這樣用戶看到的是代碼在逐行出現(xiàn)結(jié)束后瞬間變成彩色體驗(yàn)上反而更自然。5.3 那些只有踩過才知道的坑說幾個(gè)我在實(shí)際項(xiàng)目里踩過的坑都是文檔里不會(huì)寫的。第一個(gè)是中文亂碼。前面提過TextDecoder的stream: true但還有一個(gè)隱蔽的點(diǎn)如果服務(wù)端在yield時(shí)把中文字符按字節(jié)切開了前端解碼就會(huì)出問題。Java 的OutputStream寫入時(shí)如果沒指定 UTF-8 編碼默認(rèn)用平臺(tái)編碼在 Windows 上就是 GBK前端按 UTF-8 解碼必然亂碼。所以服務(wù)端一定要顯式指定response.setCharacterEncoding(UTF-8)。第二個(gè)是代理層的自動(dòng)重試。有些云廠商的負(fù)載均衡或者 API 網(wǎng)關(guān)會(huì)對(duì)失敗的請(qǐng)求自動(dòng)重試但 SSE 是長(zhǎng)連接重試會(huì)導(dǎo)致重復(fù)請(qǐng)求用戶看到回答重復(fù)。解決辦法是在請(qǐng)求頭里加一個(gè)唯一標(biāo)識(shí)服務(wù)端做冪等處理或者在網(wǎng)關(guān)層關(guān)掉自動(dòng)重試。第三個(gè)是瀏覽器連接數(shù)限制。HTTP/1.1 下同一域名最多 6 個(gè)并發(fā)連接。如果用戶開了多個(gè)標(biāo)簽頁都在對(duì)話加上頁面其他請(qǐng)求很容易把連接數(shù)占滿導(dǎo)致新請(qǐng)求排隊(duì)。解決辦法是升級(jí)到 HTTP/2多路復(fù)用不受這個(gè)限制。Nginx 配 HTTP/2 需要 HTTPS本地開發(fā)可以用自簽名證書。第四個(gè)是移動(dòng)端后臺(tái)斷連。手機(jī)瀏覽器切到后臺(tái)后SSE 連接可能被系統(tǒng)掛起或斷開。前端要監(jiān)聽visibilitychange事件切回前臺(tái)時(shí)檢查連接狀態(tài)斷了就重新發(fā)起。但重新發(fā)起意味著要重新生成所以更好的做法是服務(wù)端支持基于Last-Event-ID的續(xù)傳把已生成的部分緩存起來。5.4 一套可復(fù)用的檢查清單最后給一份排查清單遇到流式不工作時(shí)按順序查。檢查項(xiàng)預(yù)期值常見錯(cuò)誤響應(yīng) Content-Typetext/event-stream寫成 application/jsonNginx proxy_bufferingoff默認(rèn) on 導(dǎo)致攢包Nginx proxy_read_timeout大于最長(zhǎng)思考時(shí)間默認(rèn) 60s 導(dǎo)致 idle timeout服務(wù)端編碼UTF-8平臺(tái)默認(rèn)編碼導(dǎo)致亂碼前端解碼TextDecoder stream:true漏參數(shù)導(dǎo)致中文亂碼消息分隔空行 \n\n用單換行導(dǎo)致消息粘連結(jié)束標(biāo)記data: [DONE]不發(fā)送導(dǎo)致連接懸掛心跳15-30s 一次注釋行不發(fā)導(dǎo)致代理超時(shí)斷連這套鏈路我從最早的輪詢方案一路迭代過來中間踩的坑基本都在這了。SSE 本身不復(fù)雜復(fù)雜的是它要穿過瀏覽器、網(wǎng)關(guān)、負(fù)載均衡、后端框架這一整條鏈路每一層都有自己的默認(rèn)行為而這些默認(rèn)行為往往和流式的需求相沖突。理解了每一層為什么這么設(shè)計(jì)配置起來就不會(huì)是照抄而是知道改哪個(gè)參數(shù)、為什么改。代碼高亮延遲處理那個(gè)技巧是我在一個(gè)長(zhǎng)代碼回答場(chǎng)景下被用戶投訴代碼一直在閃之后才加上的效果立竿見影。如果你也在做類似的東西建議一開始就把這個(gè)策略定下來省得后面返工。