通知、聊天室、即時報價、任務進度都需要更新資料，但不一定全部都要用 WebSocket。
面試回答的重點是根據資料方向、頻率、延遲和基礎設施選擇。
Polling
前端固定時間呼叫 API：
const timer = setInterval(() => {
fetchLatestStatus();
}, 5000);優點：
- 簡單
- 使用既有 HTTP API
- 容易經過 CDN、proxy、load balancer
缺點：
- 沒有資料變化也會送 request
- 更新延遲取決於 interval
- 大量 client 可能增加 server 壓力
適合低頻、允許數秒延遲的狀態，例如背景任務進度。
Long Polling
Client 發 request 後，server 暫時不回覆，直到有新資料或 timeout。收到後 client 再建立下一個 request。
它比固定 polling 更接近即時，但 request 管理、timeout 和 server connection 成本較複雜。
SSE
Server-Sent Events 透過一條 HTTP connection，持續由 server 推送文字事件給瀏覽器。
const source = new EventSource("/api/events");
source.onmessage = (event) => {
const data = JSON.parse(event.data);
console.log(data);
};
source.onerror = () => {
console.log("connection error");
};優點：
- 瀏覽器 API 簡單
- server → client 單向推送
- 內建重連概念
- 適合文字事件串流
缺點：
- 主要是單向
- binary 不方便
- 連線數和 proxy 設定仍需注意
適合通知、log stream、AI 文字串流、即時狀態。
WebSocket
WebSocket 建立持續的雙向連線，client 和 server 都能主動傳訊息。
const socket = new WebSocket("wss://example.com/socket");
socket.onopen = () => {
socket.send(JSON.stringify({ type: "join", roomId: "123" }));
};
socket.onmessage = (event) => {
const message = JSON.parse(event.data);
console.log(message);
};適合：
- 聊天室
- 多人協作
- 遊戲
- 高頻雙向訊息
- 即時交易資訊
代價是連線生命週期和 server architecture 更複雜。
怎麼選？
| 技術 | 資料方向 | 即時性 | 適合場景 |
|---|---|---|---|
| Polling | Client 主動查詢 | 低到中 | 任務狀態、低頻更新 |
| Long Polling | Server 延後回覆 | 中 | 舊系統即時通知 |
| SSE | Server → Client | 中到高 | 通知、log、文字串流 |
| WebSocket | 雙向 | 高 | 聊天、協作、遊戲 |
如果每 30 秒更新一次就足夠，Polling 可能比維護 WebSocket 更合理。
WebSocket 實務問題
正式環境還要處理：
- reconnect 與 exponential backoff
- heartbeat / ping-pong
- token 過期與重新認證
- 重複訊息
- 訊息順序
- 斷線期間漏掉資料
- 多分頁重複連線
- server horizontal scaling
Client 不能只寫 onmessage 就算完成。
斷線重連怎麼做？
避免所有 client 同時瘋狂重連，可以使用 exponential backoff 加 jitter：
1s → 2s → 4s → 8s → max 30s重連成功後，可能需要帶 last event id、sequence number 或重新抓一次 snapshot，補齊斷線期間資料。
常見追問
SSE 可以 client 傳資料嗎？
EventSource 主要是 server → client。Client 要傳資料通常仍用一般 HTTP request。
WebSocket 可以經過 load balancer 嗎？
可以，但 load balancer 要支援 connection upgrade，後端也要考慮 sticky session 或 pub/sub，讓不同 instance 能交換訊息。
AI streaming 一定用 WebSocket 嗎？
不一定。若主要是 server 持續回傳文字，SSE 或 streaming HTTP response 通常更簡單。
面試回答模板
我會先看資料方向、更新頻率與可接受延遲。低頻狀態用 polling 最簡單；server 單向推送通知或文字串流可用 SSE；需要高頻雙向互動才選 WebSocket。WebSocket 上線時還要處理 heartbeat、斷線重連、token 過期、訊息順序、漏訊息補償與多 instance 廣播，不會只考慮前端 API。