HTML与iframe跨域PostMessage通信实战指南-html教程-PHP中文网

postmessage 是 iframe 跨域通信唯一安全、标准、可落地的方案；document.domain 和 cors 不适用。需监听 load 事件、校验 contentwindow 和 origin，targetorigin 必须写死完整地址，子页面收消息须双校验 origin 和 source，并通过 message 协议约定交互。

html与iframe跨域postmessage通信实战指南

直接说结论：postMessage 是 iframe 跨域通信唯一安全、标准、可落地的方案；document.domain 和 CORS 在弹出层或典型跨域 iframe 场景中完全不适用。

父页面发消息前必须确认 iframe.contentWindow 可用且 origin 可读

常见错误现象是调用 iframe.contentWindow.postMessage() 时抛出 TypeError: Cannot read property 'postMessage' of null，或控制台显示 Blocked a frame with origin "https://a.com" from accessing a cross-origin frame。这不是“加载慢”，而是你试图在 iframe 尚未完成 JS 环境初始化时就访问它。

必须监听 iframe 的 load 事件（不是 DOMContentLoaded 或 setTimeout）
在 load 回调里双重检查：iframe.contentWindow && iframe.contentWindow.location?.origin
Safari 某些版本对跨域 iframe 的 location.origin 返回 null，此时应 fallback 到预设白名单域名（如 'https://pay.gateway.io'）
若 iframe.src 动态切换（如 dev/staging/prod），需每次 load 后重新匹配对应 targetOrigin

targetOrigin 写成 '*' 会导致消息静默丢弃或安全失控

postMessage 发送时若 targetOrigin 填 '*'，浏览器在多数现代环境（尤其重定向后 origin 变更时）会直接丢弃消息——控制台可能无提示，消息根本没发出去。更严重的是，它放弃来源校验，使恶意页面可截获敏感数据（如 token、用户 ID）。

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

必须写死完整 origin，例如 'https://upload.example.com:8088'（协议 + 域名 + 端口缺一不可）
开发期可临时用 '*' 快速验证流程，但上线前必须改掉
如果子页面部署多环境，用配置驱动 targetOrigin，别硬编码字符串
CDN/代理网关可能重写响应头导致实际 origin 偏移，'*' 会让这类异常完全静默通过，极难排查

子页面收消息必须做双校验：event.origin === 白名单 && event.source === 预期窗口

只监听 message 事件等于开门揖盗。攻击者可在控制台伪造 postMessage，仅靠 event.data 字段做权限判断毫无意义。

用严格相等 === 校验 event.origin，禁止用 includes()、正则或模糊匹配
必须比对 event.source 是否等于你保存的 iframe.contentWindow 引用（不是 window.parent 或其他）
推荐用 Set 维护可信 origin 列表，避免硬编码字符串比较
首次通信可附带 type: "handshake" 和随机 nonce，建立双向信任链

无法获取跨域 iframe 的 DOM 元素，所有交互必须通过 message 协议约定

跨域 iframe 的 contentDocument 恒为 null，contentWindow 是受限对象，任何对其属性或方法的访问（包括 document、localStorage、cookie）都会触发 SecurityError。这不是延迟问题，是浏览器主动拦截。