前端高併發情境範例

🛑 前端甘我事？高併發情境下的前端防禦指南

今天面試被問到一題：「高併發你怎麼處理？」

當下我心裡的 OS 是：「高併發不是後端要處理的嗎？」結果講完後對方顯然不滿意。事後回想才發現，面試官要的不是背誦技術名詞，而是情境設計能力。

雖然這些東西真的遇到時，查一下文件半小時就能寫出來，但為了應付那些「愛問」的公司，我們還是得把這套「前端流量削峰術」內化成自己的邏輯。這份指南紀錄了前端在高併發情境下的核心任務：流量削峰與壓力隔離。

---

🎯 核心設計原則：別讓請求直達資料庫

在高併發情境下，前端的目標不再只是把畫面畫出來，而是要當一個聰明的「過濾器」，透過以下原則防止後端崩潰：

1. 動靜分離：不常變動的 HTML/JS/CSS 與素材（圖片、影片）通通丟給 CDN，別讓這些請求去佔用應用伺服器的頻寬。

2. 請求削峰：利用緩衝、延遲或合併請求，把尖峰流量「平滑化」。

3. 客戶端降級：系統快不行時，主動關掉非核心功能（例如：自動補完搜尋、即時進度更新）。

---

🛠 三大代表性情境範例

1. 電商秒殺/搶購系統 (Rush Sale)

挑戰：數百萬用戶在同一秒瘋狂點擊按鈕。

• 按鈕防抖與置灰：點擊後立即禁用按鈕，防止使用者因為焦慮而產生重複請求。

• 靜態資源預熱：活動開始前，利用 Service Worker 預先下載好活動頁所需的資源。

• 排隊等待機制：發送請求後進入輪詢或 WebSocket 狀態，顯示「排隊中」而非直接報錯，安撫用戶情緒。

• 驗證碼與異步化：透過驗證碼強制拉長操作路徑，人為分散瞬間的請求壓力。

2. 大數據流與無限捲動 (Infinite Scroll)

挑戰：快速滑動產生大量 API 請求，且大量 DOM 節點導致瀏覽器卡頓。

• 虛擬列表 (Virtual List)：只渲染可見視窗內的節點。即使有 10 萬筆資料，DOM 永遠只維持 10-20 個，保證瀏覽器不崩潰。

• 分頁請求與預加載：設定滑動閾值，在快滑到底前才拿下一頁。

• 請求取消 (AbortController)：當用戶切換分類或滑太快時，果斷取消過時的舊請求。

3. 直播間海量彈幕 (Live Streaming Chat)

挑戰：數萬人同時發言，頻繁的 DOM 更新與網路通訊會讓頁面直接當掉。

• 彈幕池緩衝 (Buffer)：不要收到一則就畫一次。建立緩衝池，每 500ms 批量渲染一次。

• 頻率限制與過濾：前端根據等級篩選訊息，或限制本地發言頻率。

• Canvas 渲染：針對海量彈幕，放棄 DOM，改用 Canvas 繪製以追求更高的幀數（FPS）。

---

💡 技術手段總結清單

技術手段	解決的問題	應用範例
CDN / Edge	減少伺服器頻寬壓力	全域靜態檔案分發
Service Worker	離線快取與預加載	秒殺頁面預熱
Debounce / Throttle	過度頻繁的觸發	搜尋框、視窗縮放
Request Batching	減少 HTTP 請求數量	點讚數合併計算

---

📝 結語

繞了一圈才發現，前端在高併發裡的角色，說穿了就是：「想盡辦法防止伺服器爆炸」。

透過在前端攔截無效請求、合併必要請求、優化渲染效率，我們可以把原本會壓垮後端的「海嘯」，變成一波波平緩的「浪潮」。早說嗎，原來前端也要當保全啊！＝＝

---

希望這份紀錄對下次面試有幫助。如果你有遇過更奇葩的情境，歡迎跟我分享！