優點：實現簡單，相容性極佳
缺點：高頻請求浪費資源，即時性差（依賴輪詢間隔）
延遲：高（取決於輪詢頻率）
適用場景：相容性要求高，延遲不敏感的簡單場景。
作者生涯印象最深刻的短輪詢應用程式場景是比分直播：
如圖所示，使用者進入比分直播介面，瀏覽器定時查詢賽事資訊（比分變動、黃紅牌等），假如資料有變化，則重新渲染頁面。
這種方式實作起來非常簡單可靠，但是頻繁的呼叫後端接口，會對後端效能會有影響（主要是 CPU）。同時，因為依賴輪詢間隔，頁面資料變化有延遲，使用者體驗也不算太好。
2.長輪詢
瀏覽器傳送 HTTP 請求後，伺服器 掛起連線 直到資料更新或逾時，回傳回應後瀏覽器立即啟動新請求。
優點：減少無效請求，比短輪詢即時性更好
缺點：伺服器需維護掛起連接，高並發時資源消耗大
延遲：中（取決於數據更新頻率）
適用場景：需要較好即時性且無法用 WebSocket/SSE 的場景（如訊息通知）
長輪詢最常見的應用場景是：配置中心，我們耳熟能詳的註冊中心 Nacos 、阿波羅都是依賴長輪詢機制。
3.WebSocket
基於 TCP 的全雙工協議，透過 HTTP 升級握手（Upgrade: websocket）建立持久連線（雙向即時通訊）。
優點：最低延遲，支援雙向交互，節省頻寬
缺點：實現複雜，需單獨處理連線狀態
延遲：極低
適用場景：聊天室、線上遊戲、協同編輯等 高即時雙向互動 需求
筆者曾經服務於北京一家電商公司，參與直播答題功能的研發。
直播答題整體架構見下圖：
TCP 網關的技術選型是：Netty、ProtoBuf、WebSocket ，選擇 WebSocket 是因為它支援雙向即時通信，同時 Netty 內建了 WebSocket 實作類，工程實現起來相對簡單。
4.Server Send Event(SSE)
基於 HTTP 協議，伺服器可 主動推送 資料流（如Content-Type: text/event-stream），瀏覽器透過EventSource API 監聽。
優點：原生支援斷線重連，輕量級（HTTP協定）
缺點：單向通訊（服務端--》客戶端），低版 IE 瀏覽器不支援
延遲：低（伺服器可即時推送）
適用場景：股票行情、即時日誌等 伺服器單向推送 需求。
SSE 最經典的應用場景是 ： DeepSeek web 聊天介面 ，如圖所示：
當 DeepSeek 對話方塊傳送訊息後，瀏覽器會傳送一個 HTTP 請求 ，服務端會透過 SSE 方式將資料傳回瀏覽器。
5.總結
選擇建議：
需要 簡單相容性 → 短輪詢
需要 中等即時性 → 長輪詢
只需 伺服器推送 → SSE
需要 全雙工即時互動 → WebSocket
