postmessage本身安全，但安全性取决于开发者使用方式；iframe需等load完成并校验origin+source，window.open需双向校验opener，跨标签页依赖origin+业务标识，worker无需origin校验但须严守数据契约。
postMessage本身是安全的通信机制，但它的安全性完全取决于开发者如何使用。不同运行方式下，通信链路、控制粒度和风险暴露面各不相同，必须针对性设计验证逻辑和容错策略。
iframe嵌入场景：需等load完成再发，且必须校验origin+source
iframe.contentWindow在DOM插入后立即可读，但目标页JS可能尚未执行，message监听器未注册，导致消息静默丢失。可靠做法是监听iframe.onload事件后再调用postMessage。
- 发送方必须指定精确targetOrigin（如https://widget.example.com），禁用"*"
- 接收方先比event.origin全等匹配，再确认event.source是否为当前iframe.contentWindow
- 若iframe发生重定向或刷新，contentWindow引用会失效，后续发送将抛出DOMException
- 服务端渲染（SSR）页面中，需加状态标记或防抖，避免主脚本未就绪时误发
window.open弹窗场景：依赖window.opener双向校验，防中间人替换
弹窗打开后，主页面持有其window引用，弹窗可通过window.opener反向通信。但攻击者可能劫持弹窗并篡改opener引用，因此双方都需主动验证。
- 主页面发送时，targetOrigin应与弹窗实际URL严格一致（协议、域名、端口缺一不可）
- 弹窗接收消息后，用event.source === window.opener确认来源，不能仅信origin
- 弹窗回复时，调用event.source.postMessage()，第二个参数必须传event.origin，不可硬编码
- 开发时注意http://localhost:3000与http://127.0.0.1:3000视为不同源，无法通信
跨标签页通信：无直接引用关系，靠origin+唯一标识+存储协同
标签页之间没有天然的window引用，无法像iframe或open窗口那样做source比对，必须强化origin校验，并引入业务层标识增强可信度。
- 接收方只接受来自明确白名单origin的消息（如https://app.example.com）
- 建议在event.data中携带nonce或timestamp+signature，防止重放攻击
- 可配合localStorage写入临时token，发送方先存、接收方校验后再处理消息，形成轻量握手
- 避免高频轮询或重复发送，可用BroadcastChannel作辅助协调，降低postMessage负载
Worker线程通信：无需origin校验，但需结构化数据与类型守卫
Web Worker与主线程同源运行，不受同源策略限制，因此event.origin恒为null，校验无意义。安全重心转向数据契约和执行隔离。
- 主线程与Worker间通信仍用postMessage，但发送前应做structured clone兼容性检查
- 接收方必须校验event.data.type字段，对未知type直接return，不执行后续逻辑
- 敏感操作（如调用fetch、修改DOM）禁止在Worker中进行，所有副作用必须由主线程完成
- 大对象传输建议用transfer参数移交所有权，避免序列化开销
