實現bom層面的跨域通信核心機制是window.postmessage方法。其解決方案包括：1. 發送端通過iframe元素的contentwindow屬性獲取子窗口對象并調用postmessage，指定目標源以確保安全；2. 接收端監聽message事件，驗證Event.origin后處理數據并可進行回復；3. 安全性方面必須嚴格檢查發送方源和接收方目標源，避免使用通配符’*’；4. 老舊方法如url哈希、window.name因效率低、安全性差已被淘汰；5. 實際開發中需注意時序問題、數據序列化一致性，并利用console.log、斷點調試等技巧排查問題。
要在瀏覽器對象模型（BOM）層面實現頁面的跨域通信，核心機制是利用window.postMessage方法。這基本上是現代瀏覽器中最安全、最可靠的跨域通信手段，它允許不同源的窗口（包括iframe、彈出窗口等）之間安全地交換數據。
解決方案
window.postMessage方法提供了一種受控的方式來規避同源策略，使得不同源的文檔能夠發送和接收消息。其工作原理可以簡單分為發送端和接收端。
發送端（例如，父頁面向iframe發送消息）：
父頁面可以通過其iframe元素的contentWindow屬性來獲取子頁面的window對象，然后調用postMessage。
// 父頁面 (parent.html) const iframe = document.getElementById('myIframe'); const targetOrigin = 'http://child.example.com'; // 必須指定目標源，或者使用 '*' (不推薦用于生產環境) // 確保iframe加載完畢再發送，或者在iframe加載事件中發送 iframe.onload = () => { iframe.contentWindow.postMessage('你好，iframe！這是一條來自父頁面的消息。', targetOrigin); console.log('消息已發送到iframe。'); }; // 也可以直接在某個事件中發送 // document.getElementById('sendMessageBtn').addEventListener('click', () => { // iframe.contentWindow.postMessage({ type: 'data', payload: '復雜數據對象' }, targetOrigin); // });
postMessage的第一個參數是你要發送的數據，可以是字符串、數字、布爾值、數組、對象，甚至是File對象或Blob對象等。第二個參數targetOrigin至關重要，它指定了接收消息的窗口的源。如果你不確定或想發送給任何源，可以使用’*’，但這會帶來安全風險，因為任何頁面都可以接收到你的消息。我個人建議，除非你明確知道風險并接受，否則請務必指定具體的源。
接收端（例如，iframe接收父頁面發送的消息）：
接收消息的頁面需要添加一個事件監聽器來監聽message事件。
// 子頁面 (child.html，位于 http://child.example.com) window.addEventListener('message', (event) => { // 關鍵的安全檢查：驗證消息來源的源 if (event.origin !== 'http://parent.example.com') { // 必須驗證！ console.warn('收到來自未知源的消息，已忽略。', event.origin); return; } console.log('收到消息：', event.data); console.log('消息來源：', event.origin); console.log('發送者窗口對象：', event.source); // 引用發送消息的窗口對象 // 接收到消息后，也可以回復 event.source.postMessage('收到你的消息了，父頁面！', event.origin); }); console.log('子頁面已準備好接收消息。');
這里，event對象包含了幾個有用的屬性：
- event.data: 接收到的數據。
- event.origin: 發送消息的文檔的源（協議、域名、端口）。這是進行安全驗證的關鍵。
- event.source: 對發送消息的窗口或iframe的引用。你可以用它來回復消息。
postMessage的安全性：不得不提的那些事兒
在使用window.postMessage進行跨域通信時，安全性是首要考慮的問題，甚至可以說，它比通信本身更重要。我個人覺得，很多開發者在追求功能實現的時候，往往容易忽略這一點，但一旦出了問題，那可不是鬧著玩兒的。
首先，發送方指定targetOrigin是避免消息被不當接收的關鍵。如果你把targetOrigin設為’*’，那意味著你的消息可能會被任何一個監聽message事件的頁面接收到。想象一下，你把一個包含敏感信息的消息發出去，結果被一個惡意網站的iframe給截獲了，這簡直就是災難。所以，始終明確指定目標源，比如’https://your-trusted-domain.com’，這是最基本的安全實踐。
其次，也是同樣重要的，接收方必須嚴格驗證event.origin。即使發送方指定了目標源，也不能保證接收方收到的消息就一定是來自預期的源。惡意網站完全可以偽造一個postMessage事件，并嘗試發送數據到你的頁面。如果你的接收端沒有驗證event.origin，就直接處理event.data，那么你的頁面就可能面臨跨站腳本（xss）攻擊的風險。舉個例子，如果接收到的數據被直接插入到DOM中，或者被當作JavaScript代碼執行，那攻擊者就能在你的頁面上為所欲為。所以，每次收到消息，第一件事就是if (event.origin !== ‘預期的源’) { return; }，這是鐵律，沒有商量的余地。
最后，關于數據本身，雖然postMessage支持發送復雜的數據結構，但在處理接收到的數據時，仍然要像處理任何外部輸入一樣，進行輸入驗證和凈化。不要盲目相信event.data的內容，特別是當它可能被用來構建HTML或執行腳本時。
除了postMessage，還有哪些BOM跨域通信方式？為什么它們被淘汰了？
說實話，在postMessage出現之前，前端開發者為了實現跨域通信，真是絞盡腦汁，想出了不少“奇技淫巧”。這些方法雖然在特定場景下能解決問題，但大多存在明顯的局限性或安全隱患，所以現在基本上都已經被postMessage取代了。
一個比較經典的例子是利用URL的哈希值（window.location.hash）。這種方法的思路是，父頁面和子頁面（通常是iframe）通過不斷改變URL的哈希值來傳遞信息。比如，父頁面通過修改iframe的src來設置哈希值，子頁面通過監聽hashchange事件來獲取哈希值。反之亦然，子頁面也可以通過修改自身的哈希值，然后讓父頁面通過一個中間iframe（同源）來讀取。這種方式的缺點非常明顯：數據量小，只能是字符串；需要輪詢或者頻繁修改URL導致歷史記錄混亂；而且安全性很差，哈希值是公開的，容易被劫持。
另一個是利用window.name屬性。window.name在頁面跳轉后仍然保持不變，并且可以存儲相當大的字符串（通常是幾MB）。利用這個特性，一個頁面可以在iframe中加載一個不同源的頁面，然后讓這個iframe跳轉到一個與父頁面同源的空白頁。由于window.name的值在跳轉后依然存在，父頁面就可以安全地讀取iframe的window.name來獲取之前跨域頁面設置的數據。這種方法雖然能傳輸較大數據，但操作流程非常復雜，需要兩次頁面跳轉，效率低下，而且只能單向通信，每次通信都需要重新加載iframe，這在實際應用中簡直是噩夢。
在我看來，這些老舊的方法都像是“打補丁”，為了繞過同源策略而生，但都帶著各自的“病根”。postMessage的出現，就像是給跨域通信提供了一個官方且健壯的API，它直接在瀏覽器層面解決了安全性和通信效率的問題，所以，現在幾乎所有的跨域通信場景，我們都會優先考慮postMessage。
實現postMessage時可能遇到的坑和調試技巧
即便postMessage是如此強大和現代，但在實際開發中，你還是可能會踩到一些坑，或者在調試時感到困惑。這玩意兒有時候就是這樣，理論上很清晰，實踐起來卻有各種小脾氣。
最常見的坑：時序問題
你可能會發現，有時發送的消息接收不到。這往往是時序問題。比如，你嘗試向一個尚未完全加載的iframe發送消息。postMessage是異步的，但如果目標window對象還沒準備好，消息自然就發不出去。解決方法通常是在iframe加載完成后（iframe.onload事件）再發送消息，或者在接收端準備好之后（例如，接收端發送一個“我已準備好”的消息給發送端）再開始通信。
數據序列化和反序列化
雖然postMessage支持發送復雜對象，因為它內部使用了結構化克隆算法。但有時候，為了更好的兼容性或者在一些特殊場景下，你可能會習慣性地對發送的數據進行json.stringify()，然后在接收端JSON.parse()。這本身不是問題，但要確保兩邊都保持一致。如果你發送了一個原生對象，而接收端卻嘗試JSON.parse()一個非JSON字符串，那肯定會報錯。
調試的痛點
postMessage的調試確實有點兒玄乎，因為消息是在不同的window上下文之間傳遞的，不像HTTP請求那樣能在網絡面板里一目了然。
- Console.log大法： 這是最直接有效的。在發送方和接收方的JavaScript代碼中，大量使用console.log來打印發送前的數據、接收到的數據、event.origin等關鍵信息。通過觀察控制臺的輸出，你可以判斷消息是否發出、是否收到、以及收到的內容是否正確。
- 斷點調試： 在發送和接收postMessage的代碼行設置斷點。在chrome DevTools中，你可以選擇不同的執行上下文（比如父頁面的top和iframe的iframe-name），分別在各自的上下文中進行斷點調試，觀察變量的值和代碼的執行流程。
- 模擬和簡化： 如果通信復雜，可以先寫一個最簡單的發送和接收例子，確保基礎功能正常。然后逐步添加復雜性。有時候，問題可能不是出在postMessage本身，而是你處理消息的邏輯，或者目標window對象獲取不正確。
總之，postMessage是現代Web開發中不可或缺的跨域通信利器，掌握它的安全機制和一些調試技巧，能讓你在處理復雜的前端交互時更加游刃有余。
