題干與適用場景
Reporting API 為 CSP、Permissions-Policy、Integrity-Policy、COEP、棄用與干預等瀏覽器事件提供統一報告機制。報告可以由 ReportingObserver 在頁面內讀取，也可以由瀏覽器 POST 到遠端 endpoint。題目考察你能否把瀏覽器訊號變成可靠工程觀測，同時避免把使用者資料直接送進日誌系統。
面試官考察點
- 能否區分頁面內 observer 與遠端 endpoint 的可靠性邊界。
- 能否設計
Reporting-Endpoints、報告類型路由與採樣降噪。 - 能否處理報告中的 URL、使用者代理與業務參數等隱私資訊。
- 能否把 report-only、告警、修復與回歸驗證串成閉環。
回答前需要釐清的問題
先確認目標是安全策略遷移、瀏覽器棄用升級還是當機線索收集；再確認支援的瀏覽器範圍、是否有跨網域頁面、資料保留期限與合規要求。還要問清 endpoint 是否能承受突發流量，以及是否允許把原始 URL 送到第三方。
30 秒回答框架
我會把方案分成採集、傳輸、處理與治理四層。安全策略先用 report-only 觀察，Reporting-Endpoints 把不同類型路由到受控入口；頁面 observer 用於即時除錯，遠端報告用於脫離頁面生命週期的彙整。伺服器做限流、去重、脫敏與採樣，再把高置信問題接入告警與回歸測試。報告送達沒有絕對保證，因此不能取代真實錯誤監控。
分步驟深入解答
1. 選擇採集路徑
ReportingObserver 適合開發期與頁面內診斷，可以設定 types 與 buffered。遠端 endpoint 由瀏覽器以 application/reports+json POST，頁面當機後仍可能保留線索，可靠性較適合生產彙整。兩條路徑都要處理瀏覽器相容性與報告缺失。
2. 設計 endpoint 與路由
使用 Reporting-Endpoints 宣告命名 endpoint，再由 CSP、COEP 或 Permissions-Policy 的報告指令選擇目標。按 type 分流到安全、棄用與穩定性管道；對 crash、deprecation 等沒有專屬 header 的報告準備 default endpoint。入口必須只接受預期內容類型並驗證大小。
3. 降噪與隱私
伺服器按網站、版本、報告類型與錯誤指紋去重，限制每個來源的速率，並在彙整前移除查詢參數、帳號識別與敏感路徑。只保留診斷所需欄位，設定短保留期與存取稽核。採樣率應按嚴重度與新版本變化動態調整，避免一次相容性問題放大成告警風暴。
4. 治理閉環
先在 report-only 階段建立基線，再逐步收緊策略。把新棄用報告關聯到瀏覽器版本與發布批次，修復後用自動化回歸或 WebDriver 觸發測試報告驗證。監控端點成功率、延遲、丟棄數與修復時間；報告系統故障時保留降級路徑，不阻塞頁面主流程。
高品質示範回答
我會先限定採集目標與資料邊界。策略遷移先用 report-only，利用 Reporting-Endpoints 將 CSP、Permissions-Policy 與棄用報告送到同一受控入口，再按類型路由。ReportingObserver 只承擔即時診斷，生產事實以遠端彙整為主，但我會明確瀏覽器不保證每份報告送達。
伺服器驗證 application/reports+json、限制大小與速率，按網站、版本、類型與錯誤指紋去重。URL 移除查詢參數與帳號識別，使用者代理只保留版本維度，短期保存並記錄存取稽核。告警按嚴重度、新版本增量與影響頁面採樣，修復後以回歸測試確認報告下降。整條鏈路不能阻塞頁面，也不能取代前端錯誤監控與真實使用者指標。
常見錯誤
- 只使用
ReportingObserver，忽略頁面當機會讓 observer 遺失線索。 - 直接把原始 URL、查詢參數或完整使用者代理寫入長期日誌。
- 認為設定 endpoint 後報告一定送達，未監控丟棄、限流與跨瀏覽器差異。
- 把 report-only 發現直接當成阻斷策略，跳過基線與灰度。
追問及應對
頁面內 observer 和遠端 endpoint 如何取捨？
observer 易於除錯且可按腳本邏輯處理，但依賴頁面仍在執行。遠端 endpoint 能獨立於頁面彙整，適合生產與當機線索；兩者可以並行，但要避免重複計數。
如何防止報告系統洩露使用者資訊？
在入口做欄位白名單、URL 脫敏、大小限制與速率控制；按彙整維度保留版本而非完整識別，設定短保留期、加密與稽核，並限制跨團隊讀取。
為什麼報告數量突然暴增？
先按版本、瀏覽器、網站、類型與指紋切片，區分新發布回歸、策略誤配、爬蟲流量與重複重試。檢查端點限流與採樣，再決定告警升級或回滾發布。