為什么前端項目不都采用 WebSocket？
在前端圈子里面，WebSocket 一直自帶 “高端感”，甚至有些中小廠在面試中會把 WebSocket 作為技術難點來問。
畢竟，WebSocket 能做到 全雙工通信，還能讓前端和后端像打電話一樣實時對話，聽上去就是 HTTP 的“終極替代品”。
那問題來了：既然 WebSocket 這么強，為什么今天的 Web 應用沒有全面拋棄 HTTP，只用 WebSocket？
你可能會想：微信、釘釘這些聊天軟件，不也是靠類似的技術支撐的嗎？它們能支撐上億用戶同時在線，那咱們的業務系統用 WebSocket，不就能統一交互方式、實時性直接拉滿了？
很遺憾，事情遠沒有這么簡單。
如果你真把所有接口都塞進 WebSocket，不僅不會變輕松，反而會掉進一個又一個大坑。
今天，我們就來拆解一下：
- 為什么會出現 WebSocket？
- WebSocket 的優勢都有什么？
- WebSocket 的缺陷都有啥？
- 實際開發中，WebSocket、SSE、HTTP 各自應該怎么選？
為什么會出現 WebSocket？
在 WebSocket 出現之前，前端要想實現“實時通信”，基本只能靠兩種老辦法：
- 輪詢（Polling）
- 前端每隔幾秒發一次請求問：“有新數據嗎？”
- 缺點是顯而易見的：浪費帶寬，延遲還高。
- 長輪詢（Long Polling）
- 前端發起請求，服務端不立刻返回，而是等到有新數據才響應。
- 響應完了，前端再發起新的請求。
- 延遲問題解決了一點，但依舊有大量連接在反復創建、銷毀。
這兩種方案其實都不好。
所以，在 2011 年，WebSocket 協議（RFC 6455） 橫空出世。
它的核心思想很簡單：
- 先用一次 HTTP 握手（Upgrade），然后“升級”成一條持久化的 TCP 連接。
- 從此以后，前后端可以像發短信一樣隨時互發消息，不再需要頻繁建立 HTTP 請求。
這在當年絕對是革命性的體驗：實時性大幅提升，同時 服務器壓力也大幅度下降。
也正是因為這樣，WebSocket 一度被視為 “Web 實時通信的未來”。
WebSocket 的優勢都有什么？
雖然現在大家對 WebSocket 的評價趨于理性，但不得不承認，它依舊有一些“別人替代不了”的獨家優勢：
1. 所有消息走一條連接，時序可控
傳統 HTTP 請求是 一次一條通道，并行時序靠隊列調度，沒法保證嚴格的先后順序。
而 WebSocket 不一樣：所有請求、響應、通知消息都在同一條連接上傳輸。
這意味著你能精準掌控消息的時序：誰先誰后，完全由你決定。
2. 一次鑒權，狀態長期有效
在 HTTP 世界里，每次請求都得帶上 Token、Cookie 等鑒權信息，服務端要一遍遍校驗。
WebSocket 則更簡單：連接建立時完成一次認證，后續所有消息都基于同一個連接。換句話說，它天然就是“有狀態”的通信方式，管理起來省心很多。
看起來是不是很爽？
但很遺憾，優勢只有這兩條。 剩下的都是問題.....
WebSocket 的缺陷都有啥
光看上面的介紹，你會感覺 WebSocket 真爽。
但是，如果你真的想要把 所有接口都搬到 WebSocket 上時，很快就會被教育了。
因為 WebSocket 帶來的問題，往往比它解決的問題還多：
1. 認證機制不如 HTTP 簡單
握手階段可以帶 Cookie 或 Token，但一旦連接建立，后續就是裸 TCP 流了。
想用 Header 做認證？不好意思，已經沒有 HTTP 頭了。
這就意味著你需要自己在消息體里定義認證字段，或者額外維護一套“請求上下文”。
2. 跨域風險更高
HTTP 有 CORS 來保護，WebSocket 默認是允許跨域的。
如果不額外校驗 Origin 頭，那么就非常容易出現數據泄露的問題。
3. 請求與響應要自己匹配
HTTP 天然是一問一答。
但是，WebSocket 沒這個約束，你必須用 request_id 來區分不同請求的響應，不然消息一亂就麻煩大了。
4. 中間件和生態缺失
HTTP 里日志、監控、路由、緩存都有現成中間件。
但是，WebSocket 世界？幾乎得自己造輪子，連調試都麻煩。
5. 部署和代理更復雜
不是所有代理、負載均衡器都默認支持 WebSocket。
配置不當的話，Upgrade 頭可能被吃掉，導致連接直接掛掉。
所以說，WebSocket 很酷，但坑點也很硬核。
你要是把 CRUD 接口都放進去，絕對是“自找麻煩”。
WebSocket、SSE、HTTP 各自應該怎么選
那么根據以上內容，大家應該就可以知道：WebSocket 是不可以無腦使用的。
那么具體應該怎么用呢？
1. 常規請求：老老實實用 HTTP
像用戶登錄、商品下單、列表查詢這類 標準 CRUD 操作，HTTP 永遠是最優解。
2. 單向推送：優先 SSE（EventSource）
如果你的場景是 服務端推消息給前端，比如：
- 系統通知
- 訂單進度更新
- 股票/輿情行情
這類單向實時推送，SSE 更合適：
3. 雙向交互：再考慮 WebSocket
只有在確實需要 雙向通信 的時候，才該上 WebSocket，比如：
- 聊天系統
- 在線協同編輯
- 實時白板、游戲對戰
這種場景下，客戶端要告訴服務端“我訂閱了哪個頻道”，服務端再有針對性地推送。
給大家一個表單，來更清楚的展示 websocket、SSE、長輪詢、HTTP 的使用場景：
圖片
