本文由45歲老架構師尼恩分享，感謝作者，有修訂和重新排版。
1、引言
你有沒有想過，為什麼 ChatGPT 的回答能逐字逐句地“流”出來？這一切的背後，都離不開一項關鍵技術——SSE（Server-Sent Events）！
本文從SSE（Server-Sent Events）技術的原理到示例代碼，為你通俗易懂的講解SSE技術的方方面面。
2、AI大模型實時通信技術專題
技術專題系列文章目錄如下，本文是第 4 篇：
- 《全民AI時代，大模型客户端和服務端的實時通信到底用什麼協議？》
- 《大模型時代多模型AI網關的架構設計與實現》
- 《通俗易懂：AI大模型基於SSE的實時流式響應技術原理和實踐示例》
- 《ChatGPT如何實現聊天一樣的實時交互？快速讀懂SSE實時“推”技術 》
- 《AI大模型爆火的SSE技術到底是什麼？萬字長文，一篇讀懂SSE！ 》（☜ 本文）
3、初識SSE
SSE（Server-Sent Events）是一種基於 HTTP 協議的服務器推送技術，允許服務端主動向客户端發送數據流。SSE 可以被理解為 HTTP 的一個擴展或一種特定用法。它不是一個全新的、獨立的協議，而是構建在標準 HTTP/1.1 協議之上的技術。SSE 就像是服務器打開了一個“單向數據管道”，服務器通過HTTP 擴展 可以持續不斷地流向瀏覽器，無需客户端反覆發起請求。其實很簡單的： SSE = HTTP 擴展字段 + Keepalive 長連接。SSE 提供了一種簡單、可靠的方式來實現服務器向客户端的實時數據推送。它非常適合通知、實時數據更新、日誌流和類似 ChatGPT 的逐字輸出場景。如果你只需要單向通信，SSE 往往是比 WebSocket 更簡單、更輕量的選擇。SSE 適用於服務器主動向客户端推送數據的場景，如實時通知、動態更新等。所以，目前 幾乎所有主流瀏覽器都原生支持SSE。PS：更詳細的SSE技術資料，可以進一步閲讀以下幾篇：Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSESSE技術詳解：一種全新的HTML5服務器推送事件技術詳解Web端通信方式的演進：從Ajax、JSONP 到 SSE、Websocket一文讀懂前端技術演進：盤點Web前端20年的技術變遷史網頁端IM通信技術快速入門：短輪詢、長輪詢、SSE、WebSocket搞懂現代Web端即時通訊技術一文就夠：WebSocket、socket.io、SSE4、SSE的誕生背景4.1 短輪詢、長輪詢、Flash 、 WebSocket在 SSE 技術出現之前，Web 應用要實現服務器向客户端的實時數據推送，主要依賴以下幾種技術，但它們都存在明顯的缺陷。4.1.1）短輪詢 (Polling)：原理：用短連接請求數據。客户端以固定的時間間隔（例如每秒一次）頻繁地向服務器發送請求，詢問是否有新數據。缺點：大量請求可能是無效的（無新數據），浪費服務器和帶寬資源，實時性差。短輪詢的技術流程圖：
4.1.2）長輪詢 (Long Polling)：原理：使用長連接請求數據。 客户端發送一個請求，服務器會保持這個連接打開（長連接），直到有新數據可用或超時。一旦客户端收到響應，會立即發起下一個請求。缺點：雖然減少了無效請求，但每個連接仍然需要客户端發起，服務器需要維護大量掛起的連接，實現複雜。
長輪詢 (Long Polling) 的技術突破：減少無效請求，但服務器需維護掛起連接4.1.3）基於 Flash 的解決方案：原理：利用 Adobe Flash 插件提供的 Socket 功能實現全雙工通信。缺點：依賴瀏覽器插件，在移動端（如 iPhone）不受支持，且隨着技術的發展（Flash 被淘汰）已走向消亡。基於 Flash 方法都非原生支持，效率低下或依賴外部插件。4.1.4）基於 WebSocket的解決方案：原理：在客户端與服務器之間建立一條全雙工的 TCP 長連接，雙方可隨時互相推送數據。缺點：1）需要一次額外的協議升級握手（Upgrade: websocket），對 CDN、防火牆、代理服務器的兼容性不如普通 HTTP；2）雙向通信能力在“服務器→客户端單向推送”場景下顯得過度設計，增加心跳、重連、幀解析等複雜度；3）早期瀏覽器支持不一（IE ≤ 9 無原生實現），需要 Polyfill 或 Flash 降級方案。
WebSocket全雙工通道的革命性：擺脱HTTP束縛，實現真正的實時交互（PS: WebSocket 並不僅是 Web 領域的通訊協議，它屬於複雜度較高的二進制通訊協議）。4.2 SSE 誕生的核心背景因此，Web 領域迫切需要一種標準化的、高效的、由瀏覽器原生支持的服務器到客户端的單向通信機制。這就是 SSE 誕生的核心背景。核心需求：1）簡單：易於服務器和客户端實現；2）高效：基於 HTTP/HTTPS，避免不必要的請求開銷；3）標準：成為 W3C 標準，得到瀏覽器原生支持；4）自動重連：內置連接失敗後自動重試的機制。SSE——真正的服務器推送：
5、SSE的前世今生SSE 的發展是 Web 標準化進程和實時通信需求共同推動的結果。下圖概述了其關鍵發展節點：
讓我們對圖中的關鍵階段進行詳細解讀。1）誕生背景（2006 年以前）：Web 早期只有“請求-響應”範式，實時需求（股票、IM、行情）只能靠輪詢或長輪詢，延遲高、浪費資源。Comet（長連接 iframe、jsonp、xhr-streaming 等 Hack 方案）出現，但實現複雜、瀏覽器兼容性差、佔用連接數高。業界急需一種“瀏覽器原生、基於 HTTP、單向服務器推送”的輕量機制。2）概念提出與標準化 (約 2006-2009年)：SSE 的概念最初作為 HTML5 標準的一部分被提出，由 WHATWG (Web Hypertext Application Technology Working Group) 和 W3C (World Wide Web Consortium) 共同推動。其設計思想是定義一個簡單的、基於 HTTP 的協議，允許服務器通過一個長連接持續地向客户端發送文本流。2006 年，Opera 9 在瀏覽器裏率先實現名為 Server-Sent Events 的實驗 API，用 DOM 事件把服務器推送的文本塊餵給頁面。同期 WHATWG HTML5 草案開始收錄相關章節，定義了 text/event-stream MIME 類型及“event: / data:”行協議。後來，它從龐大的 HTML5 規範中分離出來，成為了一個獨立的 W3C 標準文檔。2008 年，SSE 被正式寫入 HTML5 草案，隨後進入 W3C 標準流程。3）瀏覽器支持與推廣 (約 2010-2015年)：2011年左右，主流瀏覽器（如 Firefox、Chrome、Safari、Opera）開始陸續支持 SSE API。 Firefox 6、Chrome 6、Safari 5、Opera 11.5 陸續完成原生實現；IE 系列缺席（直到 Edge 79 才補票）。關鍵的障礙：Internet Explorer (包括 IE 11) 始終沒有支持 SSE API。這在一定程度上限制了其早期的廣泛應用，開發者通常需要為此準備降級方案（如回落到長輪詢）。隨着 Chrome、Firefox 等現代瀏覽器的市場份額不斷上升，以及移動端瀏覽器對 SSE 的良好支持，SSE 逐漸成為開發實時 Web 應用的可信選擇。2014 年 10 月：HTML5 成為 W3C Recommendation，SSE 作為官方子模塊鎖定最終語法，瀏覽器陣營格局定型。4）正式推薦與成熟 (2015年至2022 )：2015-2020 年，WebSocket 與 WebRTC 佔據實時通信話題中心，SSE 主要在企業內部儀表盤、日誌 tail 等低頻場景默默使用。SSE 由於有 “單向文本流 + 自動重連 + 輕量” 特性，所以沒有被WebSocket 與 WebRTC 踩死， 使其在 IoT 設備、移動端 WebView 中仍保有一席之地。2015年，W3C 發佈了 Server-Sent Events 的正式推薦標準，標誌着該技術的成熟和穩定。在此期間，前端生態框架（如 React、Vue.js）和後端語言（如 Node.js、Python、Java）都提供了對 SSE 的良好支持，出現了大量易用的庫和示例。5） 大模型時代的爆發（2022 至今）：雖然 WebSocket 提供了全雙工通信能力，但 SSE 因其簡單的 API、基於 HTTP 帶來的良好兼容性（如無需擔心代理或防火牆問題）、以及自動重連等特性，在只需要服務器向客户端推送數據的場景中（如新聞推送、實時行情、狀態更新、AI 處理進度流式輸出等）成為了更簡單、更合適的選擇。ChatGPT、Claude 等生成式 AI 需要“打字機”式逐 token 輸出，SSE 天然契合：1）基於 HTTP/1.1 無需升級協議，CDN 緩存友好；2）瀏覽器 EventSource API 一行代碼即可接入；3）文本流可直接承載 JSON Lines 或 markdown 片段。2022 年底起：OpenAI、Anthropic、Google Bard 均把 text/event-stream 作為官方流式回答協議，社區庫（FastAPI SSE-Star、Spring WebFlux、Node sse.js、Go gin-sse）迎來二次繁榮。6、SSE的技術特徵
SSE和WebSocket 都能建立瀏覽器與服務器的長期通信，但區別很明顯：1）SSE 是單向推送 不是雙向推送， 而且是http協議的一個擴展協議， 使用簡單、自動重連，適合文本類實時推送；2）WebSocket 是雙向通信，不是 http協議的一個擴展協議，WebSocket 更靈活，但實現相對複雜。
流程解讀：1）連接初始化：客户端使用特定的 Content-Type: text/event-stream 向服務器發起一個普通的 HTTP GET 請求。服務器確認並保持連接開放。2）數據推送：服務器通過保持打開的連接，以純文本格式（遵循 data: ...、event: ... 等規範）持續發送數據塊。每個消息以兩個換行符 \n\n 結束。3）連接容錯：如果連接因網絡問題中斷，SSE 客户端內置的機制會自動嘗試重新建立連接，極大地提高了應用的魯棒性。4）客户端處理：瀏覽器端的 EventSource API 會解析收到的數據流，觸發相應的事件（如 onmessage 或自定義事件），讓開發者能夠處理推送來的數據。SSE 的誕生是 Web 開發對簡單、高效、標準化的服務器推送技術需求的直接結果。它有效地替代了笨拙的輪詢技術，在與 WebSocket 的競爭中，找到了自身在單向數據流場景下的獨特定位。其發展歷程經歷了從概念提出、瀏覽器支持到成為正式標準的完整路徑。儘管曾受限於 IE，但在現代瀏覽器中已成為一項穩定、可靠且被廣泛採用的技術。如今，在實時通知、金融儀表盤、實時日誌跟蹤和大型語言模型（LLM）的流式響應輸出等場景中，SSE 都是首選的解決方案。7、默默無聞的SSE為何在AI大模型時代一夜爆火？SSE 最近站到聚光燈下，幾乎可以説最大的推手就是當前 AI 應用（尤其是 ChatGPT 等大型語言模型）的爆發式增長。SSE 之所以成為 AI 應用的“標配”，是因為 SSE 與 AI 所需的“打字機” 輸出模式 是 天作之合。7.1 什麼是AI大模型“打字機” 式的逐token輸出？“打字機”式 逐 token 輸出是一種流式傳輸方式，它模擬了人類打字或思考的過程。服務器不是等待 LLM 生成整個答案 後一次性發送給 用户，而是 流式輸出， 每生成一個“詞元”（token，可以粗略理解為一個詞或一個字），就立刻發送這個“詞元”。下面舉一個例子，對比 一下 傳統方式（非流式）和 “打字機” （流式）式 的過程。傳統方式（非流式）過程如下：1）你提問：“請寫一首關於春天的詩”。2）服務器端的 AI 開始思考、生成，整個過程你需要等待（可能好幾秒甚至更久）。3）AI 生成完整的詩歌：“春風拂面綠意濃，百花爭豔映晴空...”。4）服務器將整首詩作為一個完整的 JSON 對象 { "content": "春風拂面綠意濃，百花爭豔映晴空..." } 發送給客户端。5）客户端一次性收到全部內容並渲染出來。“打字機”（流式）過程如下：1）你提問：“請寫一首關於春天的詩”。2）服務器端的 AI 生成第一個 token “春”，立刻通過 SSE 發送 data: “春”。3）客户端收到“春”並顯示出來。4）AI 生成第二個 token “風”，立刻發送 data: “風”。5）客户端在“春”後面追加“風”，形成“春風”。6）後續 token “拂”、“面”、“綠”、“意”、“濃”... 依次迅速發送和追加。7）你看到的效果就是文字一個接一個地“打”在屏幕上，就像有人在遠端為你實時打字一樣。“打字機”（流式） 模式的巨大優勢：1）極低的感知延遲：用户幾乎在提問後瞬間就能看到第一個字開始輸出，無需經歷漫長的等待白屏期，體驗流暢自然。2）提供了“正在進行”的反饋：看着文字逐個出現，給人一種模型正在為你“思考”和“創作”的生動感，而不是在“沉默中宕機”。3）更高效地利用時間：用户可以在前半句還在輸出時，就開始閲讀和理解，節省了總體的認知時間。7.2 為什麼SSE跟AI大模型是“天作之合”？這正是 SSE 的設計初衷和核心優勢所在，它與 AI 流式輸出的需求完美匹配。1）單向通信的完美匹配：AI 的文本生成過程本質上是服務器到客户端的單向數據推送。客户端只需要接收，不需要在生成過程中頻繁地發送請求。SSE 的“服務器推送”模型正是為此而生，而 WebSocket 的雙向能力在這裏是多餘的。2）基於 HTTP/HTTPS，簡單且兼容：SSE 使用標準的 HTTP 協議，這意味着 SSE 易於實現和調試：任何後端框架和前端語言都能輕鬆處理。在瀏覽器中調試時，你可以在“網絡”選項卡中直接看到以文本流形式傳輸的事件，非常直觀。SSE 使用標準的 HTTP 協議，這還意味着 容易繞過網絡障礙：公司防火牆和代理通常對 HTTP/HTTPS 放行，而可能會阻攔陌生的 WebSocket 協議。這使得 SSE 的部署兼容性極好。3）內置的自動重連機制：網絡連接並不完全可靠。如果用户在接收很長的回答時網絡波動，連接中斷，SSE 客户端會自動嘗試重新連接。這對於長時間流的應用至關重要，提供了天然的魯棒性。4）輕量級的文本協議：AI 流式輸出傳輸的就是文本（UTF-8編碼）。SSE 的協議 data: ...\n\n 就是為傳輸文本片段而設計的，極其高效和簡單。WebSocket 雖然也能傳文本，但其協議設計還考慮了二進制幀、掩碼等更復雜的情況，對於純文本流來説顯得有些“重”。5）原生瀏覽器 API：現代瀏覽器都原生支持 EventSource API，開發者無需引入額外的第三方庫，即可輕鬆實現接收流式數據，減少了依賴和打包體積。
所以，SSE 站到聚光燈下的原因正是：AI 應用需要“打字機”式的逐 token 輸出體驗，而 SSE 作為一種基於 HTTP 的、簡單的、單向的服務器推送技術，是實現這種體驗最自然、最高效、最可靠的技術選擇。它就像是為這個場景量身定做的工具，沒有多餘的功能，只有恰到好處的設計。因此，當 ChatGPT 等應用席捲全球時，其背後默默無聞的 SSE 技術也終於從幕後走到了台前，被廣大開發者所重新認識和重視。8、SSE的技術原理詳解8.1 工作機制的流程圖SSE 通過一個持久的 HTTP 連接實現服務器到客户端的單向數據流。以下是其工作機制的流程圖：
以下是關鍵步驟解析。1）瀏覽器發起一個 HTTP 請求，Header 中包含：1Accept: text/event-stream2）服務器響應類型必須為：Content-Type: text/event-streamCache-Control: no-cacheConnection: keep-alive3）服務器發送事件格式（每個事件以兩個換行符結束）：event: messagedata: {"time": "2023-10-05T12:00:00", "value": "New update!"}id: 12345retry: 5000\n\n4）瀏覽器通過 EventSourceAPI 接收並處理事件。5）服務器發送 一個特殊“結束”事件，可以結束傳輸。比如，服務器發送一個如 event: end 的消息，可以結束傳輸。客户端預先監聽這個自定義的 end 事件，一旦收到，就知道傳輸結束，並可以選擇主動關閉 EventSource 連接。6）若連接中斷，瀏覽器會根據 retry字段自動重連。如果沒有收到 特殊“結束”事件， 瀏覽器 可以自動重連。8.2 SSE與其他通信方式對比不同通信技術各有適用場景，我們用表格清晰對比：
8.3 SSE的適用場景1）ChatGPT 式逐字輸出( “打字機” 式逐 詞元 token輸出)：
2）實時通知系統：a. 新訂單提醒；b. 用户消息推送；c. 審核狀態更新。3）實時數據看板：a. 股票行情；b. 設備監控數據；c. 實時日誌流。9、SSE客户端API詳解SSE的客户端實現非常簡單，瀏覽器原生提供了EventSource對象來處理與服務器的SSE連接。下面我們詳細介紹它的使用方法和核心特性。9.1 認識瀏覽器端EventSource對象瀏覽器兼容性檢測：在使用SSE前，首先需要確認當前瀏覽器是否支持EventSource（除IE/Edge外，幾乎所有現代瀏覽器都支持）。檢測方法如下：// 檢查瀏覽器是否支持SSEif ('EventSource' in window) { // 支持SSE，可正常使用 console.log('瀏覽器支持SSE');} else { // 不支持SSE，需降級處理 console.log('瀏覽器不支持SSE');}創建連接：使用EventSource創建與服務器的連接非常簡單，只需傳入服務器的SSE接口地址：// 建立與服務器的SSE連接// url為服務器提供的SSE接口地址（可同域或跨域）var source = new EventSource(url);如果需要跨域請求並攜帶Cookie，可通過第二個參數配置：// 跨域請求時，允許攜帶Cookievar source = new EventSource(url, { withCredentials: true // 默認為false，設為true表示跨域請求攜帶Cookie});連接狀態（readyState）：EventSource實例的readyState屬性用於表示當前連接狀態，只讀且有三個可能值：
可以通過該屬性判斷當前連接狀態，例如：if (source.readyState === EventSource.OPEN) { console.log('SSE連接已正常建立');}9.2 基本使用方法EventSource通過事件機制處理連接過程中的各種狀態和接收的數據，核心事件包括open、message、error。下面用流程圖展示SSE客户端的完整使用流程：
連接建立：open事件當客户端與服務器成功建立SSE連接時，會觸發open事件：// 方式1：使用onopen屬性source.onopen = function (event) { console.log('SSE連接已建立'); // 可在此處做連接成功後的初始化操作，如更新UI狀態};// 方式2：使用addEventListener（推薦，可添加多個回調）source.addEventListener('open', function (event) { console.log('SSE連接已建立（監聽方式）');}, false);接收數據：message事件當客户端收到服務器推送的數據時，會觸發message事件（默認事件，處理未指定類型的消息）：// 方式1：使用onmessage屬性source.onmessage = function (event) { // event.data為服務器推送的文本數據 var data = event.data; console.log('收到數據：', data); // 可在此處處理數據，如更新頁面內容};// 方式2：使用addEventListenersource.addEventListener('message', function (event) { var data = event.data; console.log('收到數據（監聽方式）：', data);}, false);注意：event.data始終是字符串類型，如果服務器發送的是JSON數據，需要用JSON.parse(data)轉換。連接錯誤：error事件當連接發生錯誤（如網絡中斷、服務器出錯）時，會觸發error事件：// 方式1：使用onerror屬性source.onerror = function (event) { // 可根據readyState判斷錯誤類型 if (source.readyState === EventSource.CONNECTING) { console.log('連接出錯，正在嘗試重連...'); } else { console.log('連接已關閉，無法重連'); }};// 方式2：使用addEventListenersource.addEventListener('error', function (event) { // 錯誤處理邏輯}, false);關閉連接：close()方法如果需要主動關閉SSE連接（關閉後不會自動重連），可調用close()方法：// 主動關閉SSE連接source.close();console.log('SSE連接已手動關閉');9.3 自定義事件默認情況下，服務器推送的消息會觸發message事件。但實際開發中，我們可能需要區分不同類型的消息（如"新訂單通知"和"系統公告"），這時就可以使用自定義事件。客户端通過addEventListener監聽自定義事件名，例如監聽order事件：// 監聽名為"order"的自定義事件source.addEventListener('order', function (event) { var orderData = event.data; console.log('收到新訂單：', orderData); // 處理訂單相關邏輯}, false);// 再監聽一個名為"notice"的自定義事件source.addEventListener('notice', function (event) { var noticeData = event.data; console.log('收到系統公告：', noticeData); // 處理公告相關邏輯}, false);注意：自定義事件不會觸發message事件，只會被對應的addEventListener捕獲。上面代碼中，瀏覽器對 SSE 的foonotice事件進行監聽。如何實現服務器發送foonotice事件，請看下文。12.4 AI大模型中該選擇SSE協議還是WebSocket？直接答案：對於絕大多數 chat2ai 應用 優先選擇 SSE (Server-Sent Events)。複雜的 chat2ai 應用 優先選擇WebSocket。但這並非絕對，我們需要根據具體的功能需求來決定。下面我將為你進行詳細的分析和推理。12.4.1）核心決策分析：AI聊天應用的核心交互是：1）客户端發送一條消息（一個問題）。2）服務器接收後，調用大語言模型（LLM）API。3）服務器將模型流式返回的答案（逐詞或逐句）實時推送給客户端。4）客户端實時渲染這個流式的答案，營造出“打字機”效果。這個過程的關鍵在於第3步，即服務器向客户端的單向數據推送。這正是 SSE 的絕對主場。12.4.2）為什麼 SSE 是更優的選擇？以下流程圖清晰地展示了基於不同技術方案的聊天交互過程，其中突出了SSE方案的巨大優勢：
正如上圖所示：SSE 方案在實現上更加直接和高效，因為它基於 HTTP，並且專門為服務器到客户端的單向數據流設計。此外，SSE 還帶來了以下巨大優勢：1）開發複雜度極低： a. 後端：你不需要引入任何複雜的 WebSocket 庫（如 ws, Socket.IO）。你只需要建立一個普通的 HTTP 路由（如 POST /chat 用於發送消息，GET /chat/stream 用於接收流），並在控制器中輸出 text/event-stream 格式的響應流。b. 前端：使用瀏覽器原生的 EventSource API 即可輕鬆監聽數據流，幾行代碼就能實現。無需實例化和管理 WebSocket 連接對象。2）出色的兼容性與可維護性：a. SSE 基於 HTTP，這意味着它更容易通過公司防火牆、代理，與現有的認證系統（如 Cookie、JWT）、CORS 策略協同工作，幾乎不會遇到奇怪的網絡問題。b. 在瀏覽器“網絡”選項卡中，SSE 的流清晰可見，易於調試。每個消息都是可讀的文本，調試體驗非常好。3）內置的自動重連與斷點續傳機制：a. 這是 SSE 的“殺手級特性”。網絡連接不穩定是移動端的常見問題。如果用户在接收一個很長答案的過程中網絡中斷，SSE 會在網絡恢復後自動重新連接。b. 更強大的是，SSE 協議支持發送最後一個消息的 ID。服務器可以識別出這個 ID，並判斷客户端錯過了哪些數據，從而從斷點處繼續發送，而不是重新開始生成整個回答。這既節省了昂貴的 API 調用費用，也提升了用户體驗。這在 WebSocket 中需要手動實現所有邏輯，非常複雜。12.4.3）WebSocket 的適用場景：雖然 SSE 是主流選擇，但在 chat2ai 應用變得非常複雜時，WebSocket 可能會成為更好的選擇。在以下情況下， 應該考慮使用 WebSocket：1）需要極高頻的雙向通信：不僅僅是用户提問->AI回答。例如：a. 實時協作編輯：多個用户同時編輯一份由 AI 生成的文檔，每個人的輸入都需要實時同步給其他所有人。b. AI多人遊戲：基於 AI 生成劇情和環境的實時互動遊戲，玩家的每一個動作都需要實時影響虛擬世界。2）當需要傳輸二進制數據的時候：有的聊天應用不僅支持文本，還支持實時語音對話（客户端錄音發送二進制音頻流，服務器返回 AI 語音二進制流）。WebSocket 對二進制數據的支持是天生的。3）你需要非常精確的控制心跳和連接狀態： - WebSocket 允許 手動發送 Ping/Pong 幀來檢測連接活性，雖然複雜，但給了開發人員最大的控制權。12.4.4）傳輸協議選型 結論與建議：1）起步和絕大多數情況：從 SSE 開始。這是最直接、最高效、最能給你帶來穩定體驗的選擇。使用sse 遇到的技術挑戰會更少，開發速度更快。ChatGPT、Claude 等絕大多數頂級應用都使用 SSE 不是沒有道理的。2）未來如果需要擴展：採用混合架構。如果應用未來需要加入上述 WebSocket 的適用功能（如實時語音），完全可以同時使用兩種協議：使用 SSE 專門處理 AI 文本答案的流式推送。使用 WebSocket 專門處理 實時語音、實時協作等真正的雙向通信功能。或者 強弱結合，自動切換。因此，對於 chat2ai 的傳輸協議選型答案是：優先選擇 SSE。
13、參考資料[0] EventSource API Docs[1] Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE[2] SSE技術詳解：一種全新的HTML5服務器推送事件技術[3] 使用WebSocket和SSE技術實現Web端消息推送[4] 詳解Web端通信方式的演進：從Ajax、JSONP 到 SSE、Websocket[5] 使用WebSocket和SSE技術實現Web端消息推送[6] 一文讀懂前端技術演進：盤點Web前端20年的技術變遷史[7] WebSocket從入門到精通，半小時就夠！[8] 網頁端IM通信技術快速入門：短輪詢、長輪詢、SSE、WebSocket[9] 搞懂現代Web端即時通訊技術一文就夠：WebSocket、socket.io、SSE[10] 大模型時代多模型AI網關的架構設計與實現[11] 全民AI時代，大模型客户端和服務端的實時通信到底用什麼協議？[12] 通俗易懂：AI大模型基於SSE的實時流式響應技術原理和實踐示例[13] Web端實時通信技術SSE在攜程機票業務中的實踐應用[14] ChatGPT如何實現聊天一樣的實時交互？快速讀懂SSE實時“推”技術即時通訊技術學習：- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）（本文已同步發佈於：http://www.52im.net/thread-4885-1-1.html）
