跨情境的擴充功能 messaging

​

情境邊界

​

建議的合約

• 包含明確的 type。
• 在執行動作前驗證 payload 結構。
• 對特權操作驗證寄件者情境。
• 回傳結構化的成功與錯誤回應。

type Message =
  | { type: "settings:get" }
  | { type: "settings:set"; payload: { theme: "light" | "dark" } };

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (
    !message ||
    typeof message !== "object" ||
    typeof message.type !== "string"
  ) {
    sendResponse({ ok: false, error: "invalid_message" });
    return;
  }

  if (message.type === "settings:get") {
    sendResponse({ ok: true, data: { theme: "dark" } });
    return;
  }

  if (message.type === "settings:set") {
    sendResponse({ ok: true });
    return;
  }

  sendResponse({ ok: false, error: "unknown_message" });
});

​

何時使用 sendMessage 與 connect

​

良好的架構

• 為每個功能領域建立一個訊息處理模組，而不是用單一大檔案處理所有訊息類型。
• 把特權工作集中在 background service worker。
• 用 content script 收集頁面資料，然後只轉送最低必要的 payload。
• 讓 popup 與 options 頁面保持精簡，把瀏覽器 API 呼叫委派給 background 程式碼。

​

安全規則

• 不要僅僅因為訊息來自 content script 就信任頁面衍生的內容。
• 在執行特權動作前驗證寄件者身分。
• 明確拒絕未知的訊息類型。
• 避免透過 messaging 開放泛用的「執行任意程式」或「抓任意網址」的指令。

​

常見錯誤

• 讓 UI 頁面在很多地方直接呼叫特權 API，而不是統一透過 background 路由。
• 在小型結構化 payload 就夠用時，傳送大型任意頁面快照。
• 把 content script 當成可信任的，只因為它們是你自己的程式碼，但它們其實會接觸到不受信任的頁面資料。
• 在多個情境一起演進時，忘記為訊息形狀做版本化或遷移。

​

實用模式

​

Popup 請求目前狀態

​

Content script 請求特權工作

​

即時訂閱

​

後續步驟

• 用 Storage 持久化資料。
• 在 Background script／service worker 中設計事件驅動邏輯。
• 在安全檢查清單中檢視邊界安全。