跨窗口HTML通信限制深度解析

跨窗口通信，安全第一。在浏览器世界里，唯一被官方认可、所有现代浏览器都支持的安全通信方式，就是 window.postMessage()。别指望在 HTML 标签里找到什么通信逻辑——那只会白费时间。同源策略会直接阻止你跨域操作窗口属性，而 targetOrigin 绝不能写成 '*'，必须精确指定源。监听 message 事件得在 DOM 加载之后，发送前还得先确认目标窗口是否还活着。这些细节，一个没注意，通信就可能无声失败。

回过头来，严格说 HTML 本身不会影响跨窗口通信，也不存在一个叫“HTML通信”的独立机制。真正干活的是 JavaScript 的 window.postMessage()——它才是唯一安全、通用、被所有现代浏览器支持的跨窗口通信方式。

为什么直接操作 window.opener 或 iframe.contentWindow 会报错

这不是 bug，而是浏览器强制执行的同源策略（Same-Origin Policy）。跨域时访问 window.opener.document 或 iframe.contentWindow.location，浏览器会立刻抛给你一个 DOMException: Blocked a frame with origin ... from accessing a cross-origin frame。

• 哪怕两个页面都用了 HTTPS，仅差一个子域名（比如 admin.example.com 与 api.example.com），默认也是隔离的。
• document.domain 在现代浏览器中已被逐步弃用，而且它只适用于同主域不同子域这种极窄的场景。
• HTML 的 allow 属性（比如 allow="clipboard-read"）只控制 iframe 内部权限，管不了 DOM 访问限制。

postMessage 的 targetOrigin 为什么不能写成 '*'

写成 '*' 的意思就是“发给任意源”，但生产环境必须避开——中间人可以劫持消息，恶意页面如果提前监听 message 事件，就能伪造响应或注入数据。

• 正确做法是精确指定目标源，比如 'https://app.example.com'（协议、域名、端口全匹配）。
• 如果目标页端口动态（比如本地开发用了 localhost:3000 和 localhost:5173），那就要按环境配置不同的 targetOrigin。
• 服务端不可信时，targetOrigin 设为 '/' 仅限同源，不能用于跨域场景。

接收方为什么收不到 postMessage 消息

最常见的原因是监听器注册太早，或者目标窗口引用已经失效。不是代码逻辑写错了，而是时机和状态没对上。

• 接收方必须等 DOMContentLoaded 或 window.onload 之后再绑定 addEventListener('message', ...)，否则第一条消息直接丢失。
• 发送方调用 popup.postMessage(...) 前，先检查 popup && !popup.closed，不然会触发 TypeError: Window is closed。
• 跨域 iframe 中，event.source 是唯一可靠的身份标识，不要缓存初始的 contentWindow 引用——页面一旦跳转，它就失效了。
• 移动端 Safari 在后台标签页可能延迟甚至丢弃 postMessage，关键操作建议加上超时重试和 ACK 握手。

最容易被忽略的陷阱：你以为消息发出去了，其实它根本没离开当前 JS 执行上下文——因为 targetWindow 是 null 或已关闭，而错误被静默吞掉；或者你校验了 event.origin，却没有结合 event.source.postMessage() 做双向握手，导致无法确认对方是否真的收到了。