一句話總結：多裝置同步的核心就是「一個狀態源、多端即時推送」，搞定 WebSocket 連線管理跟離線恢復，使用者在哪台裝置都能順暢出價。
你有沒有遇過這種情況——中午用電腦盯著一件古董花瓶，眼看還有 10 分鐘結標，結果老闆突然叫你開會。你掏出手機打開拍賣網站，頁面顯示的卻是 3 分鐘前的出價，等你手忙腳亂重新整理，花瓶已經被別人搶走了。
這種「裝置切換斷層」是拍賣網站的大忌。根據 Statista 2025 年的數據，68% 的線上拍賣用戶會在同一場拍賣中切換至少 2 種裝置。如果你的平台不能做到無縫同步，等於直接把將近七成的買家往外推。
今天來聊聊怎麼從技術架構到 UX 設計，把多裝置同步這件事做好。
多裝置同步到底在同步什麼？
多裝置同步是指同一個使用者在不同裝置上，能即時看到完全一致的拍賣狀態，包括當前出價、倒數計時與個人操作紀錄。 聽起來很直覺，但實際拆開來看，要同步的東西比你想像的多：
- 出價狀態：目前最高價、出價人數、你自己的出價紀錄
- 倒數計時：所有裝置的倒數必須一致，誤差不能超過 1 秒
- 通知狀態：你在手機上看過的「被超價通知」，切到電腦不該再跳一次
- 操作中間態：正在填寫的出價金額、加入的關注清單
根據 Google 的跨裝置研究，使用者對同步延遲的容忍度只有 2 秒。超過 2 秒，有 43% 的人會懷疑系統出了問題。在拍賣這種「一秒定生死」的場景裡，這個門檻只會更嚴格。
該怎麼處理 WebSocket 的多裝置連線？
拍賣即時同步的骨幹就是 WebSocket，但一個帳號同時從多台裝置連線，連線管理馬上變得棘手。 最常見的三個問題：
連線身份識別
同一個 user_id 可能同時有 3 條 WebSocket 連線（手機、平板、電腦）。後端不能只用 user_id 來區分，得額外加上 device_id 或 session_token。
實務做法是在連線握手時帶上裝置指紋：
wss://auction.example.com/ws?token=xxx&device=mobile_a3f9
如果你用 Laravel Reverb 做即時通訊，可以在 Channel 授權時注入裝置資訊，讓伺服端知道這條連線來自哪台裝置。
廣播策略：全推還是排己？
出價更新要推送給所有裝置，但「你自己的出價確認」就比較微妙。有兩派做法：
- 全推：所有裝置都收到，由前端判斷「這筆是我出的」就顯示成功動畫
- 排己推送：出價的那台裝置用 HTTP response 確認，其他裝置走 WebSocket 推送
我們建議第一種，原因是排己推送在網路不穩時容易造成狀態不一致。全推的額外頻寬成本其實很低——一筆出價事件的 JSON 大概就 200 bytes。
連線斷開與重連
手機鎖屏、切 App、進電梯，WebSocket 隨時會斷。重連機制要處理：
- 指數退避重連：1 秒、2 秒、4 秒、8 秒，最多 30 秒
- 重連後狀態回補：帶上
last_event_id，伺服端把漏掉的事件補發 - 心跳偵測：每 25 秒 ping 一次，連續 3 次沒回應就主動斷開重連
倒數計時怎麼做到全裝置一致？
倒數計時同步是最容易被低估的難題，因為每台裝置的系統時鐘可能差個幾秒。 如果你讓前端各自算倒數，A 手機顯示「剩 5 秒」的時候，B 電腦可能顯示「剩 8 秒」——使用者會崩潰。
解法是 伺服器時間校正：
- 前端連線成功時，向伺服器請求
server_time - 計算
offset = server_time - client_time - 之後所有倒數計時都用
client_time + offset來計算
這個 offset 校正要定期做（建議每 60 秒一次），因為裝置時鐘會漂移。實測下來，校正後各裝置的倒數差異可以控制在 300 毫秒以內，肉眼完全感覺不到。
如果你對拍賣倒數的心理學效果感興趣，可以看看倒數計時器的設計心理學。
實務案例：某二手精品平台的多裝置改版
一個我們實際碰過的案例：某二手精品拍賣平台（月活約 1.2 萬人），改版前的多裝置體驗慘不忍睹。使用者在手機出價後切到電腦，要等 15-20 秒才能看到自己的出價更新。客服每週收到 30+ 張「我明明出價了為什麼沒顯示」的投訴單。
改版重點：
- 把輪詢改成 WebSocket，連線管理支援多裝置
- 加入
last_event_id機制做事件回補 - 倒數計時改用伺服器時間校正
改版後，跨裝置同步延遲從 15-20 秒降到 0.8 秒，相關客訴從每週 30+ 降到 2-3 件。而且因為出價體驗變順暢，平台的每場拍賣平均出價次數增加了 22%。
這種改善幅度很典型。如果你正在規劃即時拍賣網站架構，多裝置同步應該從第一天就納入設計。
離線狀態怎麼處理才不會掉資料？
手機進電梯、Wi-Fi 斷線這些情況無法避免，關鍵是讓使用者回來時「感覺什麼都沒錯過」。 具體策略：
樂觀快取
用 Service Worker 把最近瀏覽的拍賣品快取起來。離線時使用者至少能看到「最後已知狀態」，而不是一片空白。畫面上要明確顯示「離線中 — 資料可能非最新」的提示。
事件佇列回補
重連後，前端帶著 last_event_id 跟伺服器要漏掉的事件。伺服端保留最近 5 分鐘的事件紀錄（對拍賣場景來說綽綽有餘），一次性推給客戶端。
出價衝突處理
離線時使用者按了出價按鈕怎麼辦？兩個選擇：
- 保守策略：離線時禁止出價，顯示「請恢復網路連線後再出價」
- 樂觀策略：允許出價，先存到本地佇列，重連後送出，但要處理「價格已被超越」的衝突
大多數拍賣平台選保守策略，因為拍賣出價涉及金流，樂觀策略的衝突處理太複雜，使用者也難以理解「為什麼我出價成功了結果又被取消」。
UX 設計上有哪些眉角？
技術搞定了，UX 也得跟上。幾個容易被忽略的細節：
裝置切換提示
使用者從手機切到電腦時，可以顯示一行小提示：「已從行動裝置同步最新狀態」。這不是技術必要，但能大幅提升使用者的信任感。
通知去重
「你被超價了！」這種通知，使用者在手機上看過一次就夠了。切到電腦不該再彈一次。做法是通知帶上唯一 ID，前端用 localStorage（或更好的做法是後端標記 read_at）來判斷是否已讀。
操作中間態不同步
有些東西反而不該同步——比如你在手機上正在輸入的出價金額，不需要同步到電腦上。這種「操作中間態」留在本地就好，避免造成混亂。
響應式設計配合
多裝置同步不只是資料層的事。UI 也得配合。同一筆拍賣品，在手機上可能是單欄瀑布流，在電腦上是雙欄詳情頁。狀態同步後，畫面呈現要符合各裝置的響應式設計，不能出現「資料對了但排版爆了」的窘境。
技術選型建議
最後給一張清單，幫你快速決定技術方向：
| 面向 | 建議方案 | 備註 |
|---|---|---|
| 即時通道 | WebSocket（Laravel Reverb） | 輪詢延遲太高，SSE 不支援雙向 |
| 連線管理 | device_id + session_token | 區分同帳號多裝置 |
| 時間同步 | 伺服器時間校正 + 定期重校 | 每 60 秒校正一次 |
| 離線處理 | Service Worker + 事件回補 | 保留 5 分鐘事件紀錄 |
| 通知去重 | 後端 read_at 標記 | 比 localStorage 更可靠 |
| 狀態儲存 | Redis Pub/Sub | 低延遲的跨連線廣播 |
如果你的拍賣平台還在規劃階段，想要一次把技術架構做對，找有電商與即時系統經驗的團隊聊聊會省很多彎路。
FAQ
Q：同時支援幾台裝置比較合理？ 大部分平台限制 3-5 台同時登入就夠了。再多的話，通常是帳號被盜用的徵兆，反而該觸發安全警示。
Q：WebSocket 連線數量會不會爆？ 一個使用者多 2-3 條連線，聽起來可怕，但以 Laravel Reverb 搭配 Redis 的架構來說，單台伺服器撐 5 萬條連線不是問題。1 萬月活的平台，同時在線通常在 500-1000 人，乘以 2-3 台裝置也就 1500-3000 條連線，完全沒壓力。
Q：要不要做「其他裝置踢下線」的功能？ 拍賣平台不建議。購物型平台可以限制單裝置登入，但拍賣的特性是使用者需要隨時隨地出價，強制踢下線只會讓人錯過出價機會，對平台的成交量也是傷害。
Q：PWA 跟原生 App 在多裝置同步上有差嗎？ 技術上差異不大，都是走 WebSocket。但 PWA 的 Service Worker 在背景執行有限制（各瀏覽器政策不同），原生 App 可以用推播通知補位。如果你在猶豫該做 App 還是網站，可以參考拍賣 App 與網站的比較分析。