題幹與適用場景
同一個 WebTransport 工作階段需要同時傳送即時預覽、控制訊息和大檔案。預覽希望低延遲，控制訊息必須及時到達，大檔案可以讓出頻寬。請使用 WebTransportSendGroup、sendOrder 和 getStats() 設計傳送策略，並說明優先級邊界、壅塞、重連、瀏覽器不支援和錯誤處理。
MDN 將 send group 描述為把多個串流和資料報放在同一組內，並用 sendOrder 決定組內相對傳送優先級；不同群組之間的頻寬分配由實作決定。此介面仍是實驗性能力，本文根據公開資料整理，不聲稱是公司真題。
面試官考察點
面試官關注你是否區分「組內相對順序」和「跨組公平性」，能否把業務優先級映射到可觀測的傳送佇列，並說明資料報不可靠、串流可靠有序的差異。強回答會提到 createSendGroup()、建立串流時傳入 sendGroup、sendOrder、組級 getStats()、壅塞控制和能力偵測；普通回答只說「給重要訊息加權」。
回答前需要釐清的問題
- 哪些資料可以丟棄，哪些必須可靠、有序和持久化？
- 低延遲目標、檔案吞吐目標和最大排隊時間分別是多少？
- 優先級是工作階段級固定策略，還是由使用者操作動態變化？
- 目標瀏覽器是否支援 send group，回退通道能否表達相同的業務語意？
30 秒回答框架
「我先把可靠控制訊息、即時可丟棄預覽和背景檔案傳輸分成明確的業務串流。需要比較順序的串流放入同一個 send group，透過 sendOrder 讓控制和預覽先於檔案；不要把它當成跨組頻寬保證。傳送端限制佇列和單筆大小，按 getStats() 監測排隊與完成情況，壅塞時丟棄過期預覽、暫停檔案。能力不支援時回退到獨立連線或應用程式排程，並保持控制訊息的可靠性。」
分步驟深入解答
先定義可靠性邊界。控制、權限和最終確認使用可靠串流；即時預覽可使用資料報並允許丟棄；大檔案使用可靠串流但可以低優先級。一個 send group 只解決成員之間的相對傳送順序，不會把不同群組變成可預測的權重佇列，也不會替業務完成重試。
建立群組後，把傳送串流或可寫資料報串流關聯到它，並為成員設定 sendOrder。數值關係必須在團隊協定中寫清楚，避免不同實作對「更大或更小優先」產生誤解。只有同組中參與嚴格排序的成員才比較 sendOrder；未設定順序的成員順序由實作決定。
const group = transport.createSendGroup();
const control = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 30,
});
const preview = transport.datagrams.createWritable({
sendGroup: group,
sendOrder: 20,
});
const archive = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 1,
});業務層仍要做預算：限制預覽資料報大小和過期時間，合併同一物件的最新狀態；檔案分片要有取消、重試和斷點記錄。佇列接近上限時，先丟棄過期預覽，再暫停檔案，不能丟棄控制訊息。對關鍵訊息使用確認和冪等鍵，不能因為傳送順序高就假設已經到達。
壅塞控制是傳輸層偏好，不是嚴格的業務 SLA。congestionControl 可表達偏好為低延遲或高吞吐，但實際效果取決於實作和網路。建立連線時選擇偏好，執行中用應用程式指標判斷是否應減少預覽頻率或暫停背景工作，不能只憑設定值宣稱延遲有保證。
透過群組的 getStats() 和成員級指標觀察排隊、傳送、丟棄、重試和完成延遲。把統計按群組、訊息類型、網路和工作階段版本記錄，區分「尚未傳送」「資料報遺失」和「接收端處理慢」。重連後重新建立群組、恢復可靠串流狀態，並從權威快照重建可丟棄預覽，不重用失效的串流物件。
能力偵測要在建立工作階段前完成。send group 不可用時，核心控制串流仍應能工作；可以退回獨立的可靠連線或應用程式佇列。不要為了保留視覺預覽而阻塞登入、權限或提交操作。實驗性介面上線前應有瀏覽器分組、灰度開關和關閉路徑。
高品質示範回答
我會把控制訊息、即時預覽和檔案傳輸拆成不同傳送成員，並根據可靠性選擇串流或資料報。需要比較順序的成員進入同一個 send group，控制設定最高 sendOrder，預覽其次，檔案最低；未設定順序的成員不納入嚴格比較。組內順序只表達相對優先級，跨組公平性由實作決定，所以我不會把它當成頻寬配額。
應用程式層維護訊息預算、取消、冪等和過期策略：壅塞時合併或丟棄舊預覽、暫停檔案，控制訊息保留可靠確認。congestionControl 只表達低延遲或高吞吐偏好，getStats() 用來觀測排隊和完成延遲。重連後重新建組並從快照恢復，能力不支援時保留可靠控制路徑，預覽退化或關閉。最後按群組和訊息類型監控丟棄率、延遲和使用者任務成功率。
常見錯誤
- 錯誤表現 → 把 sendOrder 當成跨組頻寬權重；失敗原因 → 規格只定義組內相對傳送順序；修正方法 → 在應用程式層做跨組排程並觀測實際結果。
- 錯誤表現 → 用高優先級取代可靠確認；失敗原因 → 傳送順序不保證到達；修正方法 → 關鍵訊息使用可靠串流、確認和冪等。
- 錯誤表現 → 壅塞時繼續排隊所有預覽和檔案；失敗原因 → 延遲和記憶體都會失控；修正方法 → 設定預算、合併最新狀態並暫停背景傳輸。
- 錯誤表現 → 重連後重用舊串流物件；失敗原因 → 串流屬於舊工作階段，狀態可能已過期；修正方法 → 重建群組、恢復權威狀態並重新訂閱。
- 錯誤表現 → 把實驗性 API 當成唯一通道；失敗原因 → 瀏覽器差異會阻斷核心操作；修正方法 → 能力偵測、灰度和可靠回退。
追問及應對
組內和組間優先級有什麼區別？
同一個 send group 內，參與排序的串流或資料報用 sendOrder 比較相對傳送順序；不同群組之間預期被公平分配，但具體比例由實作決定。需要跨組權重時，應在應用程式層拆分連線或排程佇列，並用指標驗證。
為什麼預覽不能只用高 sendOrder 保護？
優先級只影響排隊順序，不改變資料報的不可靠語意，也不保證接收端及時處理。預覽還需要過期時間、合併和丟棄策略；控制事實則要靠可靠傳輸、確認和持久化。
如何判斷暫停檔案是否有效？
記錄檔案佇列長度、預覽延遲、控制訊息完成延遲和使用者任務成功率。若暫停後控制延遲改善且預覽仍達標，可繼續；若網路恢復或業務優先級改變，再按預算恢復檔案，避免無限飢餓。
不支援 send group 時怎樣回退？
先保證可靠控制串流和核心導覽，再把預覽退回獨立資料通道、可靠串流或關閉。應用程式層保留同一訊息協定和取消規則，不能讓回退路徑失去權限、提交和錯誤處理語意。