做前端这么多年跨域通信一直是个绕不开的话题。面试的时候喜欢问实际项目里更是天天遇到比如页面里嵌了个 iframe主页面要告诉 iframe “用户登录了”再比如用 Web Worker 处理视频流算完的结果得交还给主线程。这些场景背后都有一个共同的主角——window.postMessage。这个 API 看起来就三个参数好像没什么可讲的但真要在生产环境里写稳里面门道不少尤其是 transferable 这块很多人用错了都不知道。这篇文章我会把 window.postMessage 的参数、Transferable 接口、使用注意点一次说透配合可直接改来用的示例。不管你是刚接触跨域通信的新手还是自认为已经熟门熟路的老手我都建议耐心看完特别是注意点那两章都是我踩坑踩出来的经验。1. 为什么需要 window.postMessage跨域通信的基础认知想理解 postMessage得先知道浏览器里那道著名的“墙”——同源策略。没有它任何网页都能随便读取其他网站的 Cookie、LocalStorage 或者页面内容那整个 Web 世界就乱套了。但现实业务里我们又确实需要跨域协作电商主站要嵌入聊天客服第三方支付要回跳结果低代码平台要动态加载插件。墙不能拆但可以开一扇门postMessage 就是浏览器官方提供的这扇门。1.1 浏览器的同源策略与通信困境同源策略规定只有当两个 URL 的协议、域名、端口完全一致时它们才属于同源可以互相操作对方的 DOM、读取数据。否则就是跨域。跨域的页面之间不是不能通信而是不能直接访问彼此的 DOM 和 JS 上下文。比如父页面拿到 iframe 的 contentWindow想直接改里面的变量浏览器会直接抛错。早期开发者想了很多绕过办法比如通过修改 document.domain、用图片 src 发送请求、用 window.name 传递小数据。这些方案各有各的怪癖要么只对同主域生效要么能携带的数据量极其有限要么完全没有安全边界。直到 HTML5 把 postMessage 标准化跨域通信才终于有了一个干净、可控、双向的官方通道。1.2 postMessage 的核心价值双向、异步、可控window.postMessage 的核心价值可以用三个词概括双向、异步、可控。双向意味着父页面、iframe、Worker、新开窗口之间任何一端都可以主动给另一端发消息也可以接收对方的消息实现真正意义的实时交互。异步意味着发送方调用 postMessage 后不需要等待接收方处理完成发送操作立即返回消息会被浏览器放入目标窗口的事件队列里等到合适的时机触发 message 事件。这个设计避免了两端互相阻塞但也带来了一个需要习惯的点你发完消息之后不能立刻假设对方已经拿到并处理完了。可控则体现在两个层面。第一你可以用 targetOrigin 参数精确指定消息只能发给哪个源避免消息被不相关的窗口接收第二接收方在 message 事件里能拿到 event.origin可以自己再校验一次双重保险。后面的示例会让大家看到这套机制真正跑起来是什么样。2. 参数拆解message、targetOrigin、transfer 三件套window.postMessage 的完整签名是这样的targetWindow.postMessage(message, targetOrigin, transfer)targetWindow 是你要发送到的窗口对象通常来自 iframe.contentWindow、window.opener、window.parent 或者 worker。注意postMessage 是挂在目标窗口上的方法不是 window 自己跟自己说话的工具很多人第一次用就搞混了。真正接收消息是在自己的 window 上监听 message 事件。下面逐个拆解参数。2.1 message能传什么不能传什么message 参数是你要发送的数据。理论上可以是任何结构化克隆算法支持的值包括 String、Object、Array、Map、Set、ArrayBuffer、Blob、ImageBitmap甚至 AudioData 这种较新的类型。这里有两个关键限制必须记住。第一函数和 DOM 节点不能传。为什么因为结构化克隆算法会把数据序列化到目标上下文里函数涉及作用域和闭包DOM 节点涉及浏览器内部引用这两者在设计上就无法安全地跨越窗口传递。你如果硬传浏览器会抛 DataCloneError。我曾经在一个项目里想把一个回调函数通过 postMessage 丢给 iframe 的编辑器去调用结果当场报错后来才意识到设计方向错了应该传事件标识iframe 自己绑定回调。第二message 会经历一次结构化克隆如果用 transfer则部分对象会被转移而不是克隆。这意味着即使你传一个嵌套很深的对象接收方拿到的也是全新的深拷贝副本修改它不会影响发送方的原始对象。这个机制很安全但也会带来性能开销数据量越大结构化克隆耗时越长。// 可以传 const data { type: LOGIN_SUCCESS, userId: 1024, extra: { lastLoginAt: Date.now() }, tags: [admin, vip] }; iframe.contentWindow.postMessage(data, https://app.example.com); // 不能传 const data2 { callback: () console.log(hi) }; iframe.contentWindow.postMessage(data2, https://app.example.com); // Uncaught DOMException: Failed to execute postMessage on Window: // Function could not be cloned2.2 targetOrigin安全防线不要用 * 的场合targetOrigin 指定消息可以被哪个源接收它的取值有三种情况精确的源字符串协议域名端口、字符串 *、以及 / 表示当前源。这个参数不是摆设。当 targetOrigin 指定为精确源时浏览器会检查目标窗口的源是否匹配匹配才发送不匹配则静默失败。当指定为 * 时消息会无条件发送到目标窗口不管它是什么源。很多教程为了省事推荐用 但如果你要传递敏感信息这就是事故的开端。举个例子你的主页面嵌了一个第三方广告 iframe你朝它发了一个包含用户 openid 的消息如果 targetOrigin 写成 这个 iframe 如果被恶意替换成另一个源的页面它照样能收到你的数据。反过来接收方如果不对 event.origin 做校验任何嵌到你页面里的恶意 iframe 都能投递假消息诱导你的页面执行危险操作。我的习惯是线上代码永远写精确 targetOrigin并且建议最好用变量统一管理避免散落各处。本地开发可以用 * 调试上线前必须替换。2.3 transfer可转移对象与二进制数据的性能优化第三个参数 transfer 属于大文件上传和实时画面处理的核心。它的作用是允许你把某些类型的对象所有权转移给目标上下文而不是复制一份。转移之后发送方的这个对象就变空了访问它只会得到空壳比如 ArrayBuffer 的 byteLength 变成 0。这么做最大的好处是性能。假设你有一个 200MB 的 ArrayBuffer用结构化克隆需要在内存里复制一遍然后再序列化传过去内存占用直接翻倍。用 transfer 则只是转移引用几乎零拷贝消息发出后原始缓冲区就不归你管了。对于视频帧、音频数据、WASM 内存这类大块二进制数据这个优化是肉眼可见的。// 发送方 const buffer new ArrayBuffer(1024 * 1024 * 200); worker.postMessage({ type: chunk, data: buffer }, [buffer]); console.log(buffer.byteLength); // 0已经被转移走了接收方拿到 data 时它是一个全新的 ArrayBuffer内容还在但所有权已经在接收方了。后面我会专门用一整章讲 Transferable 接口这里先记住这个特性transfer 数组里只能出现消息里包含的对象并且这些对象必须实现了 Transferable 接口。2.4 附带参数source 与 origin 的实战判断窗口接收 message 事件时事件对象上除了 data还有两个极其关键的属性origin 和 source。origin 表示消息发送方的源协议域名端口source 表示发送方的窗口对象引用。origin 是安全校验的主要依据。只有当你确认这个源是你预期的源才应该处理后面的数据。source 则可以用来回复消息比如 iframe 向父页面发消息父页面拿到 event.source 后可以直接通过 event.source.postMessage 把回复发回去而不是依赖外部保存的引用。window.addEventListener(message, (event) { // 谨慎先校验源 if (event.origin ! https://trusted.example.com) return; // 再校验数据结构 const data event.data; if (!data || typeof data.type ! string) return; // 可回复 event.source.postMessage({ type: ACK, echo: data.type }, event.origin); });这里有一个很多人忽略的点event.source 的类型不一定是 Window。当消息来自 Web Worker 时event.source 可能是 Worker 对象当消息来自同源页面时它可能是 WindowProxy。所以回复之前最好根据场景判断一下 event.source 上有没有 postMessage 方法避免直接调用报错。3. Transferable 接口深入解析从结构化克隆到零拷贝很多文章把 postMessage 和 Transferable 混着讲只说“用它提升性能”却不说清楚它的底层原理和适用边界。这一章我们把它掰开揉碎。3.1 结构化克隆算法是什么结构化克隆是浏览器内置的一种对象序列化机制用于在多个上下文之间复制数据。和 JSON.stringify 不同它支持 Date、RegExp、Map、Set、ArrayBuffer、Blob 等更多类型还能保持对象内部的引用关系比如两个属性指向同一个内部对象克隆后它们仍然指向同一个新对象。它被用在很多场景包括 IndexedDB 存储、postMessage 通信、History API 的 state 等。结构化克隆有个特点完全复制原始数据和克隆数据没有共享内存。这意味着任何一边的修改都不会影响另一边。这在大多数场景下是安全的但代价就是时间和内存。对于大数据复制开销会很明显尤其在高频场景比如每秒钟传几十帧视频中复制操作本身可能变成性能瓶颈。Transferable 接口就是为了解决这个瓶颈而存在的。它定义了一类“所有权可以转移”的对象。转移之后数据不再被复制而是把底层资源的控制权从一个上下文交接给另一个上下文。注意这里的“所有权转移”和“引用传递”不同你不能在发送方继续访问这块数据否则可能产生数据竞争和安全问题。3.2 ArrayBuffer 的转移机制ArrayBuffer 是最常见也最容易上手的 Transferable 对象。当你把一个 ArrayBuffer 放进 transfer 数组时底层二进制内存块会直接从发送方的堆中移除挂到接收方的堆上。发送方原来是这个内存块的唯一持有者现在接收方变成了唯一持有者。在实际操作中你一般这样使用// 主线程 const sab new ArrayBuffer(64); const view new Uint8Array(sab); view[0] 255; worker.postMessage(sab, [sab]); console.log(sab.byteLength); // 0 console.log(view[0]); // 0不一定view 可能变成访问空内存这里有个容易踩坑的地方如果你在同一个线程上持有这个 ArrayBuffer 的多个视图Uint8Array、DataView 等转移之后这些视图引用的内存块也会变成空。不要试图通过视图去读旧数据它已经不属于你了。正确姿势是转移完成后立即释放对原 buffer 的引用并让代码逻辑上不再使用它。// 接收方Worker 里 self.onmessage (event) { const buffer event.data; const view new Uint8Array(buffer); // view 就是完整数据可以做处理了 };3.3 其他 Transferable 对象MessagePort、ImageBitmap、OffscreenCanvasTransferable 接口不仅适用于 ArrayBuffer还有几类对象也很常用MessagePort由 MessageChannel 创建的双向通信端口把其中一个端口 postMessage 给 iframe 或 Worker就能在他们之间建立点对点通道。ImageBitmap解码后的图片位图可以从 canvas、blob 中创建。转移 ImageBitmap 比传 Blob 或 DataURL 要快得多适合图形编辑、屏幕共享。OffscreenCanvas可以在 Worker 里绘制的 canvas通过 transfer 传递控制权让主线程避免繁重的绘制计算。WebAssembly.MemoryWASM 实例的内存对象可以转移给 Worker让多个线程共享一块 WASM 内存。拿 MessagePort 举例它经常被用来在 iframe 和父页面之间建立一个“专属电话线”避免所有消息都挤在全局的 message 事件里。创建方法也很简单// 主页面 const channel new MessageChannel(); const port1 channel.port1; const iframe document.querySelector(iframe); iframe.contentWindow.postMessage(INIT_PORT, *, [channel.port2]); port1.onmessage (event) { console.log(收到 iframe 回复:, event.data); }; port1.postMessage(你好 iframe);这样主页面和 iframe 就可以通过 port1 和 iframe 内部的 port2 互发消息互不干扰其他 window.message 监听器。3.4 转移后的状态变化与常见误解关于 Transferable我见到最多的误解有三个。第一个误解是“transfer 能传任何对象”。不是的只有实现了 Transferable 接口的对象才能放进 transfer 数组。普通的 Object、Array、String你放进 transfer 数组里浏览器会直接抛异常“Value at index 0 does not have a transferable type.”。如果你不确定某个对象是否支持可以看 MDN 文档或者实验一次浏览器会给出明确报错。第二个误解是“transfer 之后数据会丢失”。不会数据本身没有消失只是所有权转移到了接收方。发送方引用的对象变为空或者失效但接收方拿到的数据是完整的。你可以在接收方继续使用这块内存。第三个误解是“transfer 比结构化克隆一定快”。对于大 ArrayBuffer确实快很多但对于小数据性能差异可以忽略而且转移会带来一个副作用发送方不能再访问原始数据。如果你的业务需要发送方继续保留数据副本就必须用克隆而不是转移。在真实场景里我经常是发送前先复制一小份出来留作备用再把大块 buffer 转移出去两头兼顾。4. 多场景实操示例iframe、Worker、页面间通信光讲理论没有说服力这一章上完整示例。每个示例我都尽量贴近真实业务而不是 demo 级别的玩具代码。4.1 iframe 父子通信完整示例场景设置主页面位于 https://app.example.com内部嵌入一个位于 https://widget.example.net 的聊天组件 iframe。用户在主站登录成功后主页面需要把用户身份传递给 iframeiframe 内部发生新消息时需要把未读数通知主页面。主页面代码const iframe document.getElementById(chatWidget); // 等待 iframe 加载完成后发送初始身份 iframe.addEventListener(load, () { const message { type: SESSION_INIT, payload: { token: getToken(), userId: getUserId(), nickname: getNickname() } }; iframe.contentWindow.postMessage(message, https://widget.example.net); }); // 监听 iframe 发来的未读数 window.addEventListener(message, (event) { if (event.origin ! https://widget.example.net) return; if (event.data event.data.type UNREAD_COUNT) { document.getElementById(unreadBadge).textContent event.data.count; } });iframe 内部代码window.addEventListener(message, (event) { // 校验消息来源 if (event.origin ! https://app.example.com) return; const data event.data; if (data.type SESSION_INIT) { sessionStorage.setItem(token, data.payload.token); initChatWidget(data.payload); // 初始化完成后通知主页面 event.source.postMessage( { type: READY, widgetId: chat-widget-1 }, event.origin ); } }); // 模拟新消息触发 function notifyUnread(count) { window.parent.postMessage({ type: UNREAD_COUNT, count }, https://app.example.com); }这个例子里有几个关键点值得一提。主页面用 iframe.addEventListener(load) 来保证 iframe 已经初始化完毕避免消息发过去的时候 iframe 里的监听器还没注册。iframe 内部用 event.source 而不是 window.parent这样更灵活万一以后 iframe 被嵌套两层event.source 始终指向实际发送方。4.2 Web Worker 中利用 transfer 传递大文件场景设置主线程读取一个用户上传的二进制大文件切成 1MB 的片交给 Worker 做哈希计算Worker 计算结果再返回主线程。为了避免复制 1MB 数据带来的额外开销我们用 transfer 转移 ArrayBuffer。主线程代码const worker new Worker(hash-worker.js); const file fileInput.files[0]; worker.onmessage (event) { if (event.data.type HASH_PROGRESS) { console.log(进度${event.data.percent}%); } else if (event.data.type HASH_DONE) { console.log(文件 SHA-256:, event.data.hash); } }; const CHUNK_SIZE 1024 * 1024; let offset 0; function sendNextChunk() { if (offset file.size) return; const slice file.slice(offset, offset CHUNK_SIZE); const reader new FileReader(); reader.onload () { const arrayBuffer reader.result; worker.postMessage( { type: CHUNK, buffer: arrayBuffer, offset }, [arrayBuffer] // 关键转移所有权避免复制 ); offset CHUNK_SIZE; sendNextChunk(); }; reader.readAsArrayBuffer(slice); } sendNextChunk();Worker 里接收时注意event.data.buffer 已经是转移后的 ArrayBuffer直接用即可不需要再手动转移回去。如果计算完成想要把结果传回主线程而结果恰好是一个大 ArrayBuffer同样可以在 postMessage 时放进 transfer 数组。// hash-worker.js self.onmessage async (event) { const data event.data; if (data.type CHUNK) { const buffer data.buffer; // 将当前块写入一个累计的哈希上下文 await appendToHashContext(buffer); postMessage({ type: HASH_PROGRESS, percent: calculatePercent(data.offset) }); } };4.3 BroadcastChannel 与 postMessage 的取舍开发多标签页应用时很多人会想能不能用 postMessage 直接给另一个标签页发消息答案是可以的如果你是通过 window.open 打开的页面可以用 window.opener.postMessage 在父子窗口之间通信。但如果两个标签页是平行打开的彼此没有 opener 关系就用不了 window.postMessage 了。这时候可以考虑 BroadcastChannel。BroadcastChannel 是 Web API 提供的另一种跨上下文通信方式它基于广播模式同一个 channel 的任意订阅者都能收到消息。使用起来比手动管理消息事件简洁得多// 标签页 A const channel new BroadcastChannel(order_update); channel.postMessage({ type: REFRESH, orderId: 12345 }); // 标签页 B const channel new BroadcastChannel(order_update); channel.onmessage (event) { console.log(event.data); };从通信原理上讲BroadcastChannel 底层也是通过结构化克隆传递数据但它不支持 transfer 参数也就没有零拷贝优化。因此大文件数据传输依然需要用 postMessage Worker 或 MessageChannel 的组合广播场景则用 BroadcastChannel 更合适。4.4 MessageChannel 与 postMessage 组合实现专属通道如果页面里多个模块都要和 iframe 通信全走 window.message 会让事件处理函数变得臃肿。推荐的做法是用 MessageChannel 创建专属通道只把唯一的 port 传给 iframe之后双方都通过这个 port 通信。这样消息不会混在全局消息流里也方便按模块拆分成不同的 handler。创建方式在 3.3 里已经演示过。在一个实际项目中我负责的主页面嵌了 8 个不同类型的 iframe每个 iframe 都通过 window.message 和主页面对话。后来消息类型越来越多全局监听器里全是 if/else 判断维护起来非常痛苦。切换到 MessageChannel 之后每个 iframe 各用一条专线主页面里只需要为每条专线绑定独立的 onmessage 回调代码清晰了不止一个量级。5. 容易踩坑的注意点安全校验与事件监听这一章是全文最需要反复阅读的部分。以下注意点不是在浏览器控制台敲两行就能发现的大多要在真实项目里踩过坑才能总结出来。5.1 为什么必须校验 event.origin即使发送方在 postMessage 时指定了 targetOrigin接收方依然必须校验 event.origin。为什么因为 targetOrigin 只约束发送时浏览器是否投递无法保证你的 message 监听器收到的每一条消息都来自诚实的人。任何嵌入页面的第三方脚本只要能拿到你的 window 引用都能调用 window.postMessage 给你发消息。校验 origin 建议用白名单模式而不是拒绝名单模式。先判断不在白名单里就 return而不是先判断在某个名单里就处理这样更安全因为默认拒绝比默认接受可靠。const ALLOWED_ORIGINS new Set([ https://app.example.com, https://widget.example.net ]); window.addEventListener(message, (event) { if (!ALLOWED_ORIGINS.has(event.origin)) return; // 安全处理 });5.2 忘记移除监听导致的内存泄漏window.addEventListener(message, handler) 用完之后如果 handler 还被引用外部关闭 iframe 或重新渲染页面监听器依旧挂在 window 上轻则造成重复执行重则内存泄漏。特别是单页应用每次进入页面都绑定新的监听器退出时不清理积累几十个监听器之后同一份 postMessage 会被执行几十次问题非常隐蔽。建议在组件销毁或页面卸载时务必 removeEventListener。如果你用的是 React在 useEffect 的 cleanup 里移除如果是 Vue在 beforeUnmount 或 onUnmounted 里移除。function handleMessage(event) { ... } window.addEventListener(message, handleMessage); // 组件卸载时 window.removeEventListener(message, handleMessage);5.3 同步阻塞与异步时序问题postMessage 本身是异步的但很多人误以为它跟 Promise 一样回调时机是微任务。实际上message 事件是一个正常的任务Task它的触发时机受浏览器事件循环调度影响。如果你在主线程执行了一个非常耗时的同步任务postMessage 的消息回调可能会延迟到同步任务结束后才执行。这个时序问题有时候会造成动画卡顿有时候会让你的 iframe 初始化逻辑迟迟不跑。解决办法有两个方向。第一尽量不在主线程做重型同步计算把耗时任务丢给 Worker避免阻塞主线程的事件循环。第二如果你确实需要保证消息传递处理的顺序可以在消息体里带上 sequence 序号接收方按序号处理避免乱序。我在做实时协作编辑器时对每一次操作都加了一个单调递增的序列号效果很好。5.4 message 序列化的边界情况前面说过postMessage 的数据会经历结构化克隆但有些边界情况依然容易被忽视。第一个是 Symbol 和 undefined。对象里的 undefined 属性会被保留但 Symbol 属性会被忽略。WeakMap、WeakSet 不能被克隆传了会抛错。Promise、Error 对象也不能直接克隆Error 虽然在某些浏览器里能克隆成空对象但不可靠建议自己转成普通对象再传。第二个是循环引用。结构化克隆支持循环引用比如对象 a.self a这会正常克隆接收方拿到的对象同样有循环引用。但如果你在其中夹杂了不被支持的类型可能中途报错。因此复杂的业务数据最好在发送前做一次白名单清洗。第三个是 Date 和 RegExp。它们会被完整克隆接收方拿到的 Date 还是 DateRegExp 还是 RegExp这在很多场景下比 JSON 方案好很多。但要注意RegExp 的 lastIndex 属性在克隆后可能变成 0如果你依赖 lastIndex 做状态要小心。6. 常见问题与排查技巧实录这一章直接上干货我实际排查过的那些问题以及排查思路。为了方便快速定位我先放一个速查表后面再展开。现象可能原因排查方向收不到任何消息targetOrigin 不匹配 / 监听器没注册 / iframe 没加载完查看浏览器开发者工具 Console 是否有报错检查监听器注册时机收到了消息但数据变成空对象数据里的函数/DOM节点/WeakMap 被克隆失败在发送前清洗数据只传安全类型大 ArrayBuffer 转移后发方数据丢了使用了 transfer转移后原 buffer 被清空确认业务上是否需要保留副本需要就复制一份再转移消息偶尔收到重复多次绑定了 message 监听器打印 addEventListener 调用栈检查是否存在重复注册iframe 刚加载时消息丢失iframe 内部代码还没有执行到监听器注册改用 load 事件或者在 iframe 初始化完成时主动通知父页面event.origin 是 null页面用的是 file:// 或 sandbox iframe修改部署方式避免 file:// 协议或移除 iframe sandbox 限制6.1 为什么收不到 postMessage 消息最常见的排查点有四个。第一是 targetOrigin 写错比如把 https 写成了 http端口少写了一个都会导致静默失败。第二是监听器绑定太晚iframe 加载完成后立即发消息但监听器在 onload 之后才绑定。第三是接收方用错对象比如在一个 iframe 里监听 message却在父页面里找日志。第四是浏览器安全策略比如 iframe 加了 sandbox 属性导致消息投递被限制此时 event.origin 可能变成 null。我的建议是先在发送方和接收方都打印日志确认发送时 targetWindow 引用正确、接收方确实注册了监听器然后逐项排除。浏览器开发者工具的网络面板不会显示 postMessage也就没有直观抓包工具日志是最可靠的调试手段。6.2 message.data 变成了空对象 / 数据丢失如果你发现接收方拿到的 message.data 是空的而不是抛错多半是因为数据中包含不支持的结构化克隆的类型。比如一个对象里某个属性是 undefined这通常没问题但如果属性是函数、Symbol 或 WeakMap浏览器可能会选择忽略它们而不是整个抛错。结果就是你发送的完整对象在接收方却少了几个字段看起来像“空对象”。解决方案很简单发送前做一次深度清洗把业务数据序列化成纯 JSON 安全的结构再放到 postMessage 里。对于 RegExp、Date 这些类型如果接收方需要可以手动转换成字符串或时间戳。不要依赖结构化克隆的“隐式容错”它会让你排查异常时无从下手。6.3 targetOrigin 不匹配导致静默失败targetOrigin 不匹配时发送方完全没有任何报错。消息被浏览器直接丢弃就像没发生过一样。典型场景是本地开发时网页跑在 http://localhost:5173而 targetOrigin 写的是线上的 https://app.example.com于是本地开发时代码怎么也跑不通上线却正常。解决这个问题有两个习惯。第一把 targetOrigin 抽成配置项区分开发和生产。第二在开发环境允许一个额外的 origin 白名单。如果你用 Vite 或 Webpack可以通过环境变量控制。const TARGET_ORIGIN process.env.NODE_ENV development ? http://localhost:5173 : https://app.example.com;6.4 transfer 后原数据被清空的排查这是使用 transfer 最常见的“翻车现场”。你可能在 postMessage 时把 ArrayBuffer 放进了 transfer 数组后来又在发送方的代码里尝试读取这个 ArrayBuffer 的内容结果发现全变成了 0。这不是 Bug而是转移的语义就是如此。如果不希望把数据转移走就不要把它放进 transfer 数组让浏览器走结构化克隆这样原数据不受影响。如果你既想保留原数据又想追求一定性能可以手动复制一份再转移。比如先 slice 出一个副本用于后续操作把原 buffer 转移出去。注意 arrayBuffer.slice() 返回的是一个新的 ArrayBuffer需要重新创建视图才能读写。6.5 与第三方页面通信的安全陷阱和第三方页面通信的时候安全边际要拉得更紧。不要信任第三方传来的任何数据包括它的类型和内容。尤其不要直接把 event.data 里的字段当作指令来执行比如 eval、innerHTML 赋值或者用它拼接 URL 后跳过校验跳转。我见过一个项目第三方 iframe 给主页面发了一个消息主页面拿着这个消息里的 url 直接 location.href url结果被恶意页面利用发了个 javascript: 协议的字符串差点变成 XSS。正确的做法是只允许你预先定义好的事件类型和结构对于未知类型一律忽略对于 url 这类字段用 new URL 解析后校验协议必须是 https:再执行跳转。7. 最后再分享两个调试小技巧写到这里postMessage 的核心内容基本讲完了。最后分享两个我平时调试跨域消息时非常实用的小技巧。第一个是统一封装 send 和 receive 工具函数。不要每次都在业务代码里直接写 iframe.contentWindow.postMessage而是封装一个 sendToFrame 函数内部自己加日志、校验 targetOrigin。这样出问题时只要看一条日志就能知道消息从哪发到哪、有没有被丢弃。export function sendToIframe(iframe, message, origin) { console.debug([postMessage send], origin, message); iframe.contentWindow.postMessage(message, origin); } export function onMessage(callback, allowedOrigins []) { return (event) { if (allowedOrigins.length !allowedOrigins.includes(event.origin)) return; console.debug([postMessage receive], event.origin, event.data); callback(event); }; }第二个是用 MessageChannel 批处理消息。有些场景下iframe 和主页面需要高频交换一些小消息比如鼠标位置、滚动状态、实时输入内容每条消息都走一次结构化克隆虽然开销小但次数多了也会影响性能。这时候可以在建立连接时创建一条 MessageChannel把所有高频小消息都通过 port.postMessage 发送port 内部的消息队列依然是异步的但至少避免了全局 message 监听器的额外查找成本代码结构也会清爽很多。postMessage 这个 API 看着小但它在现代 Web 应用里的地位一点都不低。凡是涉及跨域窗口、iframe、Worker 通信它就是最底层的那个“一”。把参数吃透、把 Transferable 搞明白、把安全习惯养好后面写任何复杂的跨域协作都不会再发怵。