題幹與適用場景
應用需要傳輸高頻游標、姿態或拖曳預覽，最新狀態比每一筆歷史更新更重要。請說明如何使用 WebTransport 的 datagrams，處理無序、遺失、大小預算、背壓、重連和不支援的瀏覽器。不要只比較 WebSocket 和 HTTP/3。
面試官考察點
- 是否理解 datagram 是不保證到達和順序的低延遲通道，不能承載關鍵事實。
- 是否能設計訊息序號、過期時間、丟棄策略和流量預算。
- 是否區分 datagram 與可靠 stream，並處理傳送佇列、壅塞和重連。
- 是否提供 HTTPS、能力檢測、降級和可觀測性方案。
回答前需要釐清的問題
- 哪些訊息是可重建的瞬時狀態，哪些必須可靠、有序或持久化？
- 單個資料報大小、更新頻率、目標延遲和可接受遺失率是多少？
- 客戶端能否從快照恢復？重連後從哪裡取得權威狀態？
- 瀏覽器與網路是否支援 WebTransport、HTTPS 和 HTTP/3？要降級到什麼傳輸？
30 秒回答框架
我會把 datagram 限定為可丟棄的最新狀態，把操作記錄、權限和最終結果放進可靠 stream 或伺服器儲存。每筆狀態帶序號、時間戳和物件版本，接收端只套用更新版本並主動丟棄過期資料；傳送端監控佇列和預算，不能無限排隊。建立連線後先發可靠快照，斷線重連重新取得權威狀態；能力檢測失敗時降級到既有可靠通道。
分步驟深入解答
1. 劃分可靠性邊界
游標和預覽可重建，適合資料報；文件操作、權限變更和提交結果必須走可靠有序通道。不要因為同一連線同時支援兩類傳輸，就混用它們的語義。
2. 設計可丟棄訊息
為物件攜帶單調序號、產生時間和工作階段版本。接收端只接受比目前版本新的訊息；超過新鮮度窗口、物件已刪除或版本落後時直接丟棄。訊息不應包含無法從快照恢復的唯一事實。
3. 控制預算與恢復
限制單筆大小、每秒傳送量和待傳送佇列長度；佇列接近上限時合併同一物件的最新狀態。重連後先透過可靠流取得快照，再恢復資料報更新，避免用舊的瞬時狀態覆蓋新快照。
4. 相容與可觀測性
僅在安全上下文中建立連線並檢測瀏覽器能力。記錄丟棄率、佇列長度、傳送失敗、重連次數和狀態修復耗時；不支援 WebTransport 時降級到 WebSocket 或輪詢，並保持相同的狀態版本協議。
高品質示範回答
我會先把訊息分成可重建瞬時狀態和不可丟失事實：游標、拖曳預覽走 datagram，文件操作、權限和提交結果走可靠 stream。每個資料報帶物件版本、序號和時間戳，接收端只接受更新版本並丟棄過期訊息；傳送端限制大小、頻率和佇列，按物件合併最新狀態。連線建立或重連時先用可靠流取得權威快照，再繼續套用資料報。全程要求 HTTPS，檢測能力並準備 WebSocket/輪詢降級，監控丟棄率、佇列、重連和快照修復時間。
常見錯誤
- 把 datagram 當成可靠、有序的訊息佇列。
- 用資料報承載權限、扣款或不可重建的業務事實。
- 沒有序號和過期時間，導致舊狀態覆蓋新狀態。
- 無限累積傳送佇列，忽略壅塞和記憶體預算。
- 重連後直接繼續發舊狀態，沒有先同步權威快照。
- 忽略 HTTPS、瀏覽器能力檢測和降級路徑。
追問及應對
遺失率升高時怎麼辦？
縮短狀態保留窗口、降低傳送頻率並合併同物件更新；關鍵事實繼續走可靠流。若狀態無法從快照恢復，應重新評估它是否適合 datagram。
如何防止亂序覆蓋？
比較物件版本或單調序號，只接受更大的版本；重連工作階段要更新 epoch，拒絕舊工作階段的訊息。
為什麼仍需要可靠流？
資料報不保證到達和順序，適合「新值覆蓋舊值」的狀態。操作日誌、快照、權限和最終確認必須具備可靠傳輸與持久化語義。