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

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

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

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

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

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

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

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

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

Rust 的 axum 框架里，SSE 端點(diǎn)長(zhǎng)這樣：

```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()) } ```

返回一個(gè)流，運(yùn)行時(shí)處理背壓、保活、客戶端斷開。沒有連接池管理，沒有 upgrade 握手，就是普通 HTTP。每個(gè)代理都認(rèn)識(shí)它，每個(gè) CDN 都能透?jìng)魉?/p>

三個(gè)頭部搞定一切

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

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

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

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

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

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

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

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

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

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

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

什么時(shí)候該用 WebSocket？

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

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

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

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

技術(shù)選型里，"夠用且簡(jiǎn)單"往往勝過"強(qiáng)大但復(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è)計(jì)實(shí)時(shí)功能前，你會(huì)先問自己"真的需要雙向嗎"，還是直接 npm install ws？