題幹與適用場景
這道題考察瀏覽器並發、記憶體模型和安全策略的綜合設計。SharedArrayBuffer 允許不同 agent 存取共享記憶體，但瀏覽器要求安全上下文與 cross-origin isolation；COOP 與 COEP 也會影響彈窗、第三方資源與嵌入關係。回答要涵蓋緩衝區擁有權、Atomics 同步、資源生命週期、跨來源依賴、降級路徑與效能觀測。
面試官考察什麼
- 能否說明為什麼需要跨來源隔離，以及它對頁面依賴的連鎖影響。
- 能否用清楚不變量設計生產者、消費者、背壓與關閉協議。
- 能否避免把 Atomics 當成無鎖萬能方案，處理忙等、阻塞等待與資料可見性。
- 能否提供不支援共享記憶體時仍可用的產品體驗與安全降級。
回答前需要澄清的問題
先確認資料區塊大小、取樣率、端到端延遲、丟幀容忍度和 Worker 數量。生產者是主執行緒、音訊執行緒還是網路 Worker？是否需要跨多個頁面共享？頁面是否依賴第三方腳本、iframe、OAuth 彈窗或無法新增 CORP/CORS 的資源？瀏覽器支援矩陣與部署環境是什麼？資料是否含個人內容，是否允許寫入持久化儲存？
30 秒回答框架
我會先驗證頁面能否在安全上下文中啟用 cross-origin isolation，再決定是否使用 SharedArrayBuffer。共享區採用固定大小環形佇列，生產者和消費者只透過索引與 Atomics 更新狀態，定義滿載、空載、取消與關閉不變量。主執行緒不執行重計算，Worker 負責處理並透過訊息回報進度與錯誤。若隔離標頭會破壞第三方資源，或瀏覽器不支援，就降級為 Transferable ArrayBuffer、分塊 postMessage 或降低取樣率，並保持相同的取消與錯誤體驗。
分步驟深入解答
1. 先建立跨來源隔離與依賴清單
確認 HTTPS、安全上下文與 crossOriginIsolated 狀態，配置相容的 COOP 與 COEP 回應標頭。逐項檢查腳本、圖片、字型、iframe、分析工具和登入彈窗是否符合嵌入策略；無法控制的第三方資源可能阻止隔離。把隔離切換作為獨立發布階段，先在報告模式和小流量驗證，再擴大範圍。
2. 設計共享記憶體布局與擁有權
為控制區與資料區分配固定布局：寫入索引、讀取索引、容量、序號、錯誤碼和關閉標記。生產者只寫入未消費槽位，消費者讀取後推進讀索引，禁止雙方同時修改同一欄位。每個槽位帶長度或版本，避免消費者讀到半寫入資料；容量不足時定義丟棄、覆蓋或背壓策略。
3. 用 Atomics 定義同步與等待
索引更新使用原子操作並明確發布順序，通知等待方處理新資料或空間可用。優先使用有界等待與批次處理，避免主執行緒忙等；Worker 可在支援的場景使用 Atomics.wait，不應阻塞 UI。所有等待都要回應取消、逾時與關閉訊號，防止頁面隱藏後 Worker 永久存活。
4. 隔離計算、錯誤與生命週期
Worker 只處理共享緩衝區中的資料，主執行緒負責 UI、權限和生命週期。初始化傳遞版本與容量，執行中回報吞吐、佇列深度與處理延遲。發生解析錯誤、記憶體不足或 Worker 崩潰時，停止生產、釋放緩衝區並讓主執行緒決定重啟或降級；不要讓半初始化的索引繼續被讀取。
5. 處理第三方資源與安全邊界
COEP 可能要求跨來源資源提供合適的 CORP 或 CORS 標頭，COOP 會改變視窗之間的關係。對無法配合的腳本、iframe 和彈窗提供同源代理、隔離子網域或不用共享記憶體的路徑；不要為了啟用高效能 API 而放寬資源邊界。共享緩衝區本身不應存放超出任務所需的敏感資料，除錯日誌要脫敏。
6. 做效能、相容與降級驗證
用基準測量吞吐、尾延遲、GC 壓力、Worker 重啟與頁面隱藏後資源釋放。測試空佇列、滿佇列、快速生產、慢速消費、重複關閉、跨版本布局與異常資料。透過能力檢測選擇 SharedArrayBuffer、Transferable 分塊或普通訊息；降級必須保留取消、進度、錯誤與最終結果語意。
高品質示範回答
我會先確認 HTTPS 與 cross-origin isolation，並檢查 COOP、COEP 對腳本、iframe、分析工具和登入彈窗的影響。共享區採用固定布局環形佇列，控制區保存讀寫索引、容量、序號和關閉標記；生產者只寫空槽，消費者讀完後推進索引，Atomics 負責可見性和通知。Worker 執行計算，主執行緒只管理 UI 與生命週期，所有等待支援逾時、取消與頁面隱藏清理。第三方資源無法滿足隔離時，使用同源代理、隔離子網域或 Transferable ArrayBuffer 分塊降級，不放寬安全邊界。指標涵蓋吞吐、尾延遲、佇列深度、記憶體、重啟和降級比例；測試涵蓋滿載、亂序關閉、異常資料與跨版本布局，確保三種路徑有一致的錯誤與進度體驗。
常見錯誤
- 只加 COOP/COEP，不檢查第三方資源和彈窗是否會失效。
- 讓多個 agent 隨意寫同一索引或槽位，沒有擁有權不變量。
- 用忙等占滿主執行緒，或讓 Worker 無限等待且無法取消。
- 把共享記憶體布局當作隱式協議，不攜帶版本、長度與關閉狀態。
- Worker 崩潰後繼續重用舊緩衝區，造成半初始化或資料誤讀。
- 為啟用 SharedArrayBuffer 而放寬跨來源資源策略。
- 降級只更換傳輸方式，卻遺失取消、進度、錯誤與資源清理語意。
追問及應對
為什麼不能只用 postMessage？
postMessage 配合 Transferable 通常更簡單、相容性更好，但高頻小區塊傳輸可能帶來排程與複製管理成本。是否使用共享記憶體要看延遲、吞吐、除錯複雜度、安全標頭與瀏覽器覆蓋，不應預設共享記憶體更快。
cross-origin isolation 會影響 OAuth 彈窗嗎？
COOP 可能改變新視窗與 opener 的瀏覽上下文關係，登入流程需要實測。可以使用同源回呼頁、隔離子網域或不啟用共享記憶體的登入入口，並在發布前驗證返回、關閉與錯誤路徑。
佇列滿了應該丟幀還是阻塞？
依據業務價值與延遲預算決定。即時預覽可以丟棄舊幀，離線轉碼應施加背壓或排隊；無論選擇什麼，都要記錄丟棄、積壓與恢復指標，避免靜默遺失關鍵資料。
SharedArrayBuffer 在某個瀏覽器不可用怎麼辦？
啟動時做能力檢測，選擇 Transferable 分塊、普通訊息或降低取樣率。降級路徑使用相同的取消、進度與錯誤協議，並監控各路徑比例，不能在執行中假設共享記憶體一定可用。