說到即時聊天系統的技術選型，很多人第一反應就是「當然用 WebSocket 啊」，但真的是這樣嗎？就拿前面那套免 WebSocket 的在線客服系統來說，它跑在普通虛擬主機、寶塔環境上，靠的就是 AJAX 輪詢。這其實點出了一個很實際的問題：不是所有場景都適合 WebSocket，選錯了反而給自己挖坑。
AJAX 輪詢到底是怎麼運作的
簡單講，AJAX 輪詢就是前端每隔一段時間（比方說 2 秒）主動問伺服器一次：「有新訊息嗎？」有就拿回來，沒有就下次再問。聽起來有點笨，對吧？但它的最大優勢是——相容性極好。PHP 7.4、MySQL、無框架、無 Composer，連寶塔面板都能直接跑，不用額外裝 Node.js 或配置長連接服務。對中小型客服系統、留言板這種並發量不高的場景，這套方案部署成本低到讓人安心。
WebSocket 的優勢與代價
WebSocket 走的是全雙工長連接，伺服器有新訊息能「主動推」給前端，延遲通常在毫秒級，而且省掉了反覆建立 HTTP 連接的開銷。高併發的場景下，像是上千人同時在線的直播彈幕、多人協作白板、股票行情推送，WebSocket 幾乎是唯一解。
但代價也很現實。它需要伺服器端常駐進程，普通共享虛擬主機往往不支援；還得處理斷線重連、心跳保活、負載均衡時的連接黏滯問題。你以為省了輪詢的流量，結果運維複雜度翻了好幾倍。
那到底怎麼選？
我的經驗是這樣——先問自己兩個問題：你的同時在線人數大概多少？你的伺服器環境能不能跑長連接？
- 在線人數幾十到一兩百、環境是共享主機或寶塔：AJAX 輪詢完全夠用，別自討苦吃。
- 需要毫秒級推送、併發上千、有獨立伺服器或雲主機：那就上 WebSocket。
還有個折衷方案常被忽略：長輪詢（Long Polling）。它讓請求「掛」在伺服器端直到有新資料才返回，介於兩者之間，延遲比普通輪詢低，又不需要 WebSocket 那套基建。
說到底，技術沒有高低之分，只有合不合適。前面那套客服系統選 AJAX 輪詢，不是技術落後，而是精準匹配了「普通虛擬主機也能跑」這個核心需求。工程師最該戒掉的，恰恰是「唯新技術論」的執念。
評論（6）
之前也遇過同樣的窘境，虛擬主機不能跑常駐進程，最後只能乖乖用輪詢，能用就好
所以大概是幾百人同時在線才會需要換 WebSocket？想有個大概的參考值
長輪詢聽起來不錯，但實際部署上有比普通輪詢複雜很多嗎
真的，一堆專案根本沒到那個量級就先被 WebSocket 的維運搞死，選擇適合的比較重要
「唯新技術論」這個詞真貼切，工具順手比趕流行重要多了
輪詢的間隔時間要怎麼抓也是門學問，設太短怕把伺服器打爆，設太長又怕訊息太頓