題目與適用場景
一個 HTTPS 網頁要幫助使用者設定 USB 裝置。使用者點擊「連接裝置」後，瀏覽器應顯示明確授權提示；頁面要處理不支援的瀏覽器、嵌入 iframe、裝置斷開、權限拒絕與重新整理恢復。
請說明能力檢測、使用者手勢、來源與 Permissions Policy、裝置篩選、資料最小化、錯誤體驗、漸進增強與測試策略。頁面不能載入時靜默掃描或把裝置資料送到第三方分析服務。
面試官在考察什麼
面試官會看你是否理解 WebUSB 是受權限控制的強大 Web API，而不是普通的 DOM 裝置清單。MDN 說明瀏覽器會在連接請求時詢問使用者；Permissions API 的結果會受安全上下文、Permissions Policy、使用者互動與提示狀態共同影響。
優秀回答會把授權來源、頂層頁面、嵌入策略、裝置過濾與連線生命週期一起考慮。Chrome 文件也強調由使用者作出最終授權決定，並建議明確設定 Permissions Policy。
30 秒回答框架
「頁面先檢測安全上下文與 navigator.usb 能力，不支援時提供一般說明與原生工具連結。使用者點擊按鈕時才呼叫 requestDevice()，並用精確的廠商與產品篩選器減少誤選。回應頭的 Permissions Policy 只允許可信來源，嵌入頁面預設拒絕。連接後只讀取完成任務所需介面，監聽斷線事件並提示重新連接。拒絕、斷線與瀏覽器不支援都顯示下一步。」
分步深入設計
第一步：確定信任邊界與業務目標
明確頁面只需設定哪些命令與資料，裝置是否包含敏感資訊，是否必須使用 WebUSB。若裝置已有更專用的瀏覽器 API 或原生工具，先進行評估。前端不應讀取所有介面。
第二步：做能力檢測與漸進增強
檢查 HTTPS、瀏覽器能力與必要 API 方法。不具備能力時提供文件、驅動下載、原生應用或人工支援路徑；能力檢測只決定增強分支，不能假設 API 存在就一定能取得授權。
第三步：把授權綁定到使用者手勢
requestDevice() 應由明確點擊或鍵盤操作觸發，按鈕文案說明會彈出瀏覽器權限提示。不要在頁面載入、計時器、隱藏 iframe 或非同步回呼中偷偷請求。錯誤要區分取消、策略阻止、不支援與未匹配。
第四步：收緊來源與 Permissions Policy
在回應頭明確配置 Permissions-Policy: usb=(self) 或更窄的可信來源清單。若頁面被嵌入，要確認頂層來源、iframe allow 屬性與策略共同允許；不要把權限開放給所有第三方。CSP、Trusted Types 與依賴稽核仍要保護頁面。
第五步：精確篩選並最小化裝置存取
篩選器限制廠商、產品或協定，避免展示無關裝置。連接後只列舉必要配置與介面，設定讀寫逾時與訊息大小上限，校驗裝置回應格式。不要把序號、原始封包或身分資料寫入分析日誌。
第六步：處理連線、斷線與重新整理
監聽 connect 與 disconnect 事件，展示裝置名稱、目前步驟與重連操作。斷線時停止輪詢並清理控制代碼；重連要再次確認篩選與目前任務。重新整理後不能假定之前的連線仍有效。
第七步：設計錯誤與隱私體驗
使用者取消授權不應顯示「系統故障」。策略阻止要提示管理員或嵌入者，未匹配要指導插入正確型號。錯誤日誌只記錄類別與關聯 ID；向第三方送診斷前要取得獨立同意並脫敏。
第八步：驗證跨環境與安全回歸
測試不安全上下文、不同瀏覽器、iframe、策略阻止、使用者拒絕、無匹配裝置、重複點擊、斷線、休眠喚醒與惡意裝置回應。檢查請求始終由手勢觸發、策略只允許預期來源，以及降級模式仍能完成說明流程。
取捨、邊界與資訊增益
更窄的裝置篩選器減少誤選與隱私暴露，卻可能讓舊韌體無法匹配；可用版本化配置維護相容範圍。自動重連改善體驗，但不能繞過新的使用者選擇或把舊控制代碼當作可信狀態。
Permissions Policy 能限制嵌入來源，卻不是裝置本身授權；瀏覽器提示仍由使用者決定。漸進增強增加設計與測試成本，但能把能力差異轉化為清晰下一步。
高品質示範回答
「我會把 WebUSB 當作受來源與使用者授權約束的增強能力。頁面在 HTTPS 下檢測 API，不支援時提供原生工具或說明。只有使用者點擊連接按鈕時才呼叫 requestDevice()，並使用精確篩選器。回應頭只允許可信來源使用 USB，嵌入 iframe 還要核對頂層策略與 allow。
連接後只存取設定所需介面，校驗回應、限制逾時與資料大小，不把原始封包寫入日誌。監聽斷線、清理控制代碼並提示重連；重新整理後要求使用者重新選擇。取消、策略阻止、未匹配與不支援分別給出下一步。」
常見錯誤
- 頁面載入時自動呼叫
requestDevice()。 權限請求必須對應明確使用者手勢。 - 把 WebUSB 當作普通裝置枚舉。 它受安全上下文、策略與瀏覽器權限共同限制。
- 篩選器空白或過寬。 使用者可能誤選無關裝置，頁面也讀取不必要資料。
- 把 USB 權限開放給所有 iframe。 第三方來源會擴大裝置暴露面。
- 用舊連線控制代碼自動恢復。 重新整理、斷線與權限狀態都可能改變。
- 把原始裝置封包寫入日誌。 診斷資料可能包含敏感資訊或序號。
- 只支援 Chromium。 不支援 WebUSB 的使用者需要可用降級路徑。
- 把拒絕授權顯示成伺服器錯誤。 使用者應知道如何重試或聯絡管理員。
追問與參考答案
為什麼必須由使用者手勢觸發？
裝置存取會影響隱私與安全，瀏覽器需要讓使用者知道哪個來源要求哪個裝置。手勢也是權限提示時機的約束。
Permissions Policy 和瀏覽器提示有什麼關係？
策略先決定文件是否有資格使用能力；即使策略允許，瀏覽器仍會依來源、上下文與使用者選擇顯示提示。兩層都通過才可能連接。
如何支援斷線後重連？
停止讀寫與輪詢，清理控制代碼，監聽重新連接事件並讓使用者確認匹配裝置。不能在背景無限重試。
為什麼不讀取所有裝置介面做診斷？
最小存取減少隱私、協定誤操作與驅動相容風險。診斷應使用明確動作、最小欄位與獨立日誌同意。
不支援 WebUSB 時怎麼辦？
提供說明、驅動或原生工具下載、瀏覽器相容提示和人工支援。核心目標不應只剩「請換瀏覽器」。