題幹與適用場景
即時協作服務有數萬長連線，目前使用第三方 WebSocket 套件。Node.js 22.4 將 WebSocket 標記為穩定，團隊希望減少依賴。請說明相容性、連線生命週期、背壓、認證、可觀測性與回滾。
面試官考察點
考察你是否區分 API 穩定與生產鏈路成熟，能否設計連線上限、心跳、廣播背壓、優雅關閉與安全升級，並用真實指標驗證替換收益。
回答前需要釐清的問題
先確認客戶端協定、代理是否支援 WebSocket、訊息大小與峰值連線；再問認證續期、跨節點廣播、斷線重連與區域故障。也要確認現有套件依賴的擴充能力與必須保留的行為。
30 秒回答
「我會先做 API 與協定差異清單，確認 Node 22.4+ 執行環境、代理與客戶端相容。伺服器為每條連線設定認證、心跳、閒置與訊息大小限制，廣播透過有界佇列處理背壓，關閉時先拒絕新連線再排空。先影子和小比例實例比較連線成功率、斷線率、P95 延遲、記憶體與 CPU，並保留第三方套件開關以便快速回退。」
分步驟深入解答
驗證執行環境與協定
Node 文件說明 WebSocket 自 v22.4.0 起不再是實驗特性；仍需鎖定 Node 版本、客戶端握手、擴充、代理逾時與 TLS 設定。
設計連線生命週期
建立連線時完成身分與權限校驗，設定最大閒置、心跳與關閉碼。服務重啟使用排空窗口，先停止接收新連線，再向客戶端發送重連提示。
處理背壓與訊息大小
每條連線維護有界發送佇列，達到門檻時丟棄可重建訊息、降級或斷開慢消費者。限制框與聚合訊息大小，避免單一客戶端佔滿事件迴圈與記憶體。
保證認證與授權
握手驗證短期憑證，訊息級操作再次檢查租戶與資源權限。憑證續期失敗應關閉連線並要求重新認證，不能只依賴初始登入。
設計橫向擴展
節點只保存本地連線狀態，跨節點事件經訊息匯流排路由；為訂閱建立版本或游標，重連可補發遺漏事件而非重複全量廣播。
灰度、監控與回滾
先在內部租戶與 1% 流量啟用，比較握手失敗、連線存活、重連、佇列丟棄、P95 延遲、記憶體與 CPU。保留舊實作設定，發現協定或資源回歸立即切回。
高品質示範回答
我不會因為 API 穩定就直接替換。先鎖定 Node 22.4+、代理與客戶端相容性，再設計握手認證、心跳、閒置逾時、訊息上限與有界發送佇列。跨節點只共享事件與游標，重連補發缺口。灰度比較握手成功率、斷線/重連、佇列丟棄、P95、記憶體與 CPU，舊套件保持可切換，指標回歸就回滾。
常見錯誤
把穩定 API 等同完整替代
第三方套件可能提供擴充、壓縮或重連行為；必須列出差異並驗證客戶端。
沒有慢消費者策略
無界佇列會耗盡記憶體；應限制佇列、丟棄可重建訊息或斷開連線。
只在握手時授權
長連線期間權限可能撤銷；敏感操作需要訊息級校驗或政策版本。
重啟時立即殺連線
這會製造重連風暴；使用排空、抖動與明確關閉碼。
追問及應對
如何控制重連風暴？
回傳明確關閉原因，客戶端使用指數退避與隨機抖動，伺服器對 IP、租戶與帳號設定速率限制。
什麼時候保留第三方套件？
若需要原生 API 未涵蓋的擴充、壓縮、代理相容或成熟監控，替換收益不足就繼續使用，並記錄評估邊界。
如何測試背壓？
注入慢客戶端與突發廣播，觀察佇列上限、丟棄策略、事件迴圈延遲與記憶體曲線。
如何保證跨節點順序？
為每個訂閱流分配單調游標，訊息匯流排攜帶版本；客戶端按游標檢測缺口並請求補發。