SSE 不是另一條「即時協定」，而是一個故意不結束的 HTTP 回應——伺服器用 text/event-stream 持續寫事件，客戶端用 EventSource 接。

WebSocket 那篇已經把選型判準講清楚：客戶端需不需要低延遲地說話。本篇不重做那張對照表，也不重講 Upgrade／Ping-Pong。這裡要補的是另一半——當答案是「幾乎只要伺服器推」時，你實際會碰到的線協定、重連語意、以及中間層怎麼把一條「看起來很簡單」的串流弄壞。

事件是「欄位列 + 空行」組成的文字塊；伺服器寫什麼，客戶端就解什麼——沒有隱藏的 frame 標頭。

1 · 一則事件長什麼樣

以 : 開頭的是註解（常見心跳）；多行 data: 會用 \n 接成單一 payload。事件以空行結束——少寫那一行，客戶端會一直等你「講完」。

2 · 互動：把一段串流餵進解析器

三個最容易踩的規則都可以在這裡當場驗：(1) 把某則的 id: 42 改成只剩 id:，游標不是「維持原值」而是被重設成空字串，而且後面的事件都跟著沒有 id。(2) 刪掉某個空行，那一塊就永遠停在緩衝區——台帳最後一個框會變成紅色虛線，位元組帳的「結尾未終止」會告訴你卡了幾 bytes。(3) 切換 CRLF 不會改變任何一則事件的內容，只會改變位元組數：三種行終止符在規範裡是等價的，但帳單不同。

2 · 回應標頭的最低配置

四列是「必須同時成立」的組合，不是先後步驟：前兩列決定瀏覽器要不要把它當 SSE 讀，後兩列決定這條連線能不能活著。最右欄就是排查順序——一則都收不到先查 Content-Type，收到舊資料先查 Cache-Control，反覆重連先查 Connection 與中間層逾時。

還有兩件常被漏掉的事：(1) 關掉反向代理／應用層的 response buffering（或顯式 flush）；(2) 若經過 gzip／Brotli 中間層，確認它不會把「未結束的 body」整段捂住。SSE 的延遲不是協定算力問題，幾乎都是「誰把位元組暫時藏起來了」。

readyState 只有三態；真正的產品能力在「斷線後帶著游標回來」。

1 · 三態，不是四態

stateDiagram-v2
    [*] --> CONNECTING
    CONNECTING --> OPEN: 標頭正確
    CONNECTING --> CONNECTING: 等待重試間隔
    OPEN --> CONNECTING: 閃斷自動重連
    OPEN --> CLOSED: 主動 close
    CONNECTING --> CLOSED: 致命錯誤
    CLOSED --> [*]

三態的 readyState 依序是 CONNECTING 0、OPEN 1、CLOSED 2。要看的是 OPEN 折回 CONNECTING 那一條邊：閃斷不會把 EventSource 推進 CLOSED，它自己退回 CONNECTING 重試——這就是 SSE 沒有 WebSocket 那個 CLOSING 態的原因。只有「主動 close」與「致命錯誤」兩條邊會真的走進 CLOSED，而 CLOSED 是終點，不會再自動回頭。

與 WebSocket 不同，EventSource 沒有 CLOSING。網路閃斷時，實作會回到 CONNECTING 並自動重試——除非你呼叫了 close()，或伺服器以會終結重連的方式回應（例如某些瀏覽器對 204／明確錯誤的處理）。面試若把 WS 的四態背到 SSE 上，會直接露餡。

2 · Last-Event-ID 補洞契約

sequenceDiagram
    participant C as 客戶端
    participant S as 伺服器
    S-->>C: event id 3
    Note over C: 游標記為 3
    S--xC: 連線中斷
    Note over S: 續產生 4、5
    C->>S: 重連帶 Last-Event-ID 3
    S-->>C: 重放 4
    S-->>C: 重放 5

補洞是兩邊各出一半力：斷線（--x 那條邊）之後的第一個請求由客戶端發起，它只負責把最後一個 id 帶回去；能不能補得起來則取決於伺服器手上還有沒有可依游標重放的 4、5。任一邊缺席都補不了洞——事件沒寫 id，或後端沒保留可重放的日誌，斷線就等於丟資料。

這條契約分成兩邊：客戶端記住最後 id 並自動帶上；伺服器必須能依游標重放或從日誌／佇列續讀。若你的事件根本沒寫 id，或後端把 SSE 當「純 fire-and-forget 日誌管」，斷線就等於丟資料——協定幫不了你。

限制解除之後，單向推播不再需要為了「連線名額」去付 WebSocket 的全套維運成本。

HTTP/1.1 時代，瀏覽器對同一 origin 大約只給 6 條並行連線。開一條常駐 SSE，等於永久佔掉六分之一——同一頁再開儀表板、通知、進度條就開始互相排擠。這是當年許多團隊「明明只是推播卻上 WebSocket」的主因之一。

HTTP/2 多路復用之後，多條 SSE 可以共用同一條 TCP／TLS 連線上的不同 stream。連線名額稅消失，SSE 的工程帳變成：

• 協定簡單：curl／瀏覽器 Network 面板直接可讀。
• 重連內建：少寫一整套心跳與退避（WS 篇花整節補的東西）。
• 中間層友善：多數 CDN／LB 本來就懂長 HTTP。

SSE 在開發機「秒出字」，上了邊緣節點卻一分鐘才吐第一包——幾乎總是緩衝與 idle timeout。

1 · 誰在捂住你的位元組

2 · 心跳是給中間層看的，不是給業務看的

註解行 : keepalive\n\n 不觸發 message，卻能重置代理的 idle 計時器。間隔要對齊基礎設施的最短 timeout（常見 15–60s），而不是對齊業務事件頻率。業務很吵時不必狂發心跳；業務很安靜時，心跳就是連線的生命線。

把「逐 token 吐出」當成 SSE 事件流時，面試該講的是取消傳播與讀取側背壓，不是 prefill／decode。

推論服務化那篇已經覆蓋 Prefill／Decode、continuous batching 與 KV。這裡只留協定接縫：

• 取消：使用者點 Stop → 客戶端 EventSource.close()（或 abort fetch stream）→ 邊緣／API 層停止讀上游 → 儘速把取消傳到推論排程，避免 GPU 繼續為已丟棄的請求解碼。
• 背壓：SSE 跑在 TCP 上，客戶端讀得慢會讓傳送緩衝堆積；若應用層仍無上限地 write，最終體現為記憶體與延遲膨脹。實務上要有「未刷新事件上限」或改為可丟棄的中間狀態（只留最新進度）。
• 結束語意：常見用具名事件 event: done 或最後一則 data: [DONE] 約定；然後伺服器結束 body。不要依賴「瀏覽器自己猜結束」。

同一條串流，斷在不同的位元組、id 發得多疏、伺服器保留多深，決定了補送幾筆、重複幾筆、真正丟掉幾筆。

最值得動手的是「多久發一次 id」：把它從每則調成每 5 則，客戶端手上的 Last-Event-ID 會倒退，重複筆數立刻從 0 跳起來——這就是為什麼「續接」不是瀏覽器自動重連給的，而是每則事件都發 id 加上伺服器能依游標重放才成立。調到 0（完全不發 id）更極端：重連時帶不出任何游標，伺服器只能從保留窗口的頭開始重播。兩個模型假設要講明：伺服器在缺口期間仍以 4 則/秒 的假設速率繼續產生事件（所以重連等待越久、要補的越多）；重複筆數的算法假設 id 是連續序號，實務上若用不連續的 offset／ULID，結論相同但要換成「游標之後有幾筆」。

把 SSE 講成「HTTP 長回應上的事件游標協定」，並畫清與 WebSocket／推論服務的責任邊界。