題幹與適用場景
一個已安裝的 PWA 要在應用程式圖示顯示未讀數量。請說明 Badging API 的能力偵測、更新與清除流程，以及瀏覽器不支援或呼叫失敗時的降級方案。
面試官考察點
- 是否知道
navigator.setAppBadge()與clearAppBadge()只在支援的安全情境中可用。 - 是否區分頁面與 Service Worker 的
WorkerNavigator能力，並處理回傳 Promise 的失敗。 - 是否把 API 當作提示層，而不是未讀資料的事實來源。
- 是否提供標題、站內計數和可存取名稱等可感知降級，並控制頻繁更新。
回答前需要澄清的問題
- 目標是已安裝 PWA 的應用程式圖示，還是一般瀏覽器分頁？
- 未讀數量的權威來源、刷新策略和多分頁一致性是什麼？
- 是否需要離線更新、背景推播，以及哪些瀏覽器和作業系統必須涵蓋？
- 螢幕閱讀器使用者如何取得相同資訊，數量是否需要去識別或截斷？
30 秒回答框架
我會把徽章當成可選提示層。只在 HTTPS 下偵測 navigator.setAppBadge，以伺服器同步的未讀數更新，檢查 Promise 失敗；數量為零時呼叫 clearAppBadge。不支援或失敗時保留站內未讀計數、標題或 favicon 標記，並用可存取文字表達狀態。頁面和 Service Worker 共用同一計數協定，更新做節流，不能因徽章失敗阻塞訊息讀取。
分步驟深入解答
1. 確認能力與顯示邊界
Badging API 面向已安裝 Web 應用程式的圖示；W3C 2026 草案將 setAppBadge 與 clearAppBadge 放在 Navigator 和 WorkerNavigator 上。它是安全情境能力，瀏覽器可以不實作或改變顯示形式，因此不能承諾跨平台顯示精確數字。
2. 以權威未讀數驅動更新
客戶端從伺服器或本地同步層取得非負整數，先做上限與去重，再呼叫 navigator.setAppBadge(count)。count 為 0 時可呼叫 clearAppBadge()；若只想顯示有未讀標記，也可不傳數字。每次呼叫都處理 Promise rejection，記錄能力和錯誤類型，不記錄訊息內容。
3. 設計頁面與背景路徑
前台頁面可在收到同步事件後更新；Service Worker 處理背景事件時使用 self.navigator 的對應能力（以實際瀏覽器支援為準）。兩條路徑都只能寫入同一版本化計數，避免舊事件覆蓋新數值。應用程式重新開啟時重新拉取權威數量，不能把圖示徽章當資料庫。
4. 失敗降級與無障礙
能力缺失、非安全情境、未安裝或呼叫失敗時，保留應用程式內未讀清單、導覽列計數和文件標題提示，並在介面提供可讀文字，例如「有 3 則未讀訊息」。aria-live 只播報變化且要節流，避免把視覺徽章當唯一通道。徽章失敗不影響訊息讀取與已讀操作。
高品質示範回答
我會先確認產品要覆蓋的是已安裝 PWA 圖示，而不是一般分頁。HTTPS 頁面偵測 navigator.setAppBadge，以伺服器同步的非負未讀數驅動更新，零值呼叫 clearAppBadge，並捕獲 Promise 失敗。頁面和 Service Worker 都只消費同一版本化計數，應用程式啟動時重新同步，避免舊事件覆蓋新值。Badging API 支援有限且平台可能把大數顯示成標記，所以我同時保留站內計數、標題或 favicon 降級，並用節流後的可存取文字讓螢幕閱讀器獲得相同狀態。徽章只是提示層，失敗不能阻塞訊息讀取。
常見錯誤
- 把 Badging API 當成所有瀏覽器分頁都支援的精確數字顯示。
- 未檢查 HTTPS、安裝狀態、方法存在性或 Promise rejection。
- 將徽章數量作為未讀資料的唯一儲存，導致刷新或多裝置不一致。
- 頁面和 Service Worker 各自維護計數，舊事件覆蓋新狀態。
- 只提供圖示顏色變化，沒有標題、站內計數或可存取文字降級。
- 每則訊息都立即呼叫 API，造成抖動、耗電和無意義更新。
追問及應對
為什麼不能只更新 favicon？
favicon 只影響分頁或書籤，不能表達已安裝應用程式圖示狀態。應把 Badging API、favicon、標題和站內計數組合成按能力選擇的提示層。
傳入 4000 會顯示什麼？
使用者代理可以把大數壓縮成 99+ 等形式，也可以只顯示標記，因此產品應限制顯示上限並在站內提供準確數字。
如何測試降級？
涵蓋安全情境與非安全情境、未安裝 PWA、缺少方法、Promise rejection、零值清除、背景事件亂序和螢幕閱讀器文字；每種情況都驗證訊息資料鏈路仍可用。