瀏覽器藏了10年的單行代碼，讓W(xué)ebSocket成了冤大頭

2015年，瀏覽器廠商往JavaScript里塞了一行代碼，然后集體沉默。沒人教，文檔 bury 在角落，Stack Overflow 上搜到的全是 WebSocket 教程。結(jié)果過去十年，無數(shù)程序員為實時推送寫了成千上萬行重連邏輯、心跳檢測、狀態(tài)恢復(fù)——而答案早就躺在那兒，一行搞定。

這行代碼是 new EventSource('/events')。它做的事情和 WebSocket 很像，但哲學(xué)完全相反：WebSocket 是"你們隨便聊"，EventSource（服務(wù)器發(fā)送事件，SSE）是"服務(wù)器說，客戶端聽"。

大多數(shù)實時場景根本不需要雙向?qū)υ挕?/b>股價跳動、構(gòu)建日志、通知紅點、直播彈幕——都是服務(wù)器推、客戶端收。用 WebSocket 做這些，就像為了收快遞專門雇個雙向?qū)χv的保安，SSE 則是門鈴響了去開門，完事。

一行代碼的暴力美學(xué)

EventSource 的 API 設(shè)計帶著一種老派的傲慢：連接、監(jiān)聽、完事。

```javascript const source = new EventSource('/events'); source.onmessage = e => document.querySelector('#feed').textContent = e.data; ```

沒有 npm install，沒有 onclose 回調(diào)，沒有指數(shù)退避的重連算法。瀏覽器自動處理斷線重連，規(guī)范強制要求。你寫的代碼只管消費消息，基礎(chǔ)設(shè)施的臟活瀏覽器包了。

對比 WebSocket 的典型實現(xiàn)：onopen 握手、onerror 降級、onclose 啟動定時器、重連后比對消息 ID 補漏。這些代碼在無數(shù)項目里被復(fù)制粘貼，調(diào)試過凌晨三點的偶發(fā)斷連，而 SSE 的用戶根本沒意識到這些問題存在。

Rust 的 axum 框架里，SSE 端點長這樣：

```rust async fn events() -> Sse>> { let stream = stream::repeat_with(|| Event::default().data("update")) .map(Ok) .throttle(Duration::from_secs(1)); Sse::new(stream).keep_alive(KeepAlive::default()) } ```

返回一個流，運行時處理背壓、保活、客戶端斷開。沒有連接池管理，沒有 upgrade 握手，就是普通 HTTP。每個代理都認識它，每個 CDN 都能透傳它。

三個頭部搞定一切

SSE 的協(xié)議規(guī)范短得像個玩笑：

``` Content-Type: text/event-stream Cache-Control: no-cache Connection: keep-alive ```

服務(wù)器發(fā)以 data: 開頭的行，瀏覽器解析。沒有幀編碼，沒有掩碼，沒有操作碼。文本流，換行分割，HTTP 從頭到尾。

WebSocket 為了兼容 HTTP 握手，先偽裝成 HTTP，再 upgrade 成獨立協(xié)議。這個設(shè)計在 2011 年情有可原——當(dāng)時很多中間件不認識 WebSocket——但現(xiàn)在成了歷史包袱。防火墻、負載均衡、企業(yè)代理，每多一層都可能 upgrade 失敗。

SSE 不走 upgrade，它就是 HTTP。公司內(nèi)網(wǎng)的老舊代理？認識。需要走 CDN 邊緣緩存？可以。想加個認證中間件？標(biāo)準(zhǔn) Cookie/Header 直接復(fù)用。

協(xié)議簡單到作弊。

自動恢復(fù)：被低估的殺手特性

WebSocket 斷線后，開發(fā)者要面對一堆決策：多久重試？退避策略用線性還是指數(shù)？重連后怎么知道漏了哪些消息？要不要服務(wù)端維護消息隊列？

SSE 的規(guī)范直接規(guī)定了自動重連，瀏覽器實現(xiàn)它。斷線后，瀏覽器按退避算法自己連，連上后繼續(xù)收。服務(wù)端不需要為"客戶端剛重連"這個狀態(tài)寫特殊邏輯。

當(dāng)然，消息丟失問題還在。但 SSE 支持 Last-Event-ID 頭部，重連時自動帶上最后收到的消息 ID，服務(wù)端可以據(jù)此補發(fā)。這個機制是可選的，簡單場景直接忽略，復(fù)雜場景按需實現(xiàn)——而不是像 WebSocket 那樣，重連邏輯是必答題。

一個類比：WebSocket 像租了輛跑車，動力強勁但得自己保養(yǎng)；SSE 像地鐵，時刻表固定，壞了等下一班，你不用管調(diào)度。

什么時候該用 WebSocket？

不是全面替代。聊天室、多人協(xié)同編輯、實時游戲——這些需要客戶端頻繁發(fā)消息的，WebSocket 的雙向通道更自然。但問問自己：你的功能真的需要雙向嗎？

Dashboard 實時數(shù)據(jù)、CI 構(gòu)建日志、股票行情、社交 Feed、進度條——這些占"實時功能"的絕大多數(shù)。它們用 SSE 更輕、更穩(wěn)、代碼更少。

有個細節(jié)很多人沒注意：SSE 天然支持瀏覽器的事件流接口，可以 addEventListener 監(jiān)聽特定事件類型，做路由分發(fā)。WebSocket 收到消息要自己解析路由。

另一個被忽略的點：SSE 基于 HTTP，所以能享受 HTTP/2 的多路復(fù)用。一個 TCP 連接可以承載多個 SSE 流，瀏覽器自動調(diào)度。WebSocket 一個連接就是一個連接，開多了就是資源競爭。

技術(shù)選型里，"夠用且簡單"往往勝過"強大但復(fù)雜"。

原文作者 Vivian Voss 在文末留了句話：「One rather appreciates infrastructure that does not require a babysitter.」（人總該欣賞那些不需要保姆的基礎(chǔ)設(shè)施。）

這句話的刻薄之處在于，它暗示了很多程序員正在做的事情——寫重連邏輯、調(diào)心跳間隔、排查代理問題——本可以不存在。不是技術(shù)深度的問題，是信息差的問題。2015 年就有的標(biāo)準(zhǔn)，2025 年還在被忽視。

下次設(shè)計實時功能前，你會先問自己"真的需要雙向嗎"，還是直接 npm install ws？