跨窗口通信唯一安全方式是 JavaScript 的 window.postMessage()；同源策略禁止直接操作跨域窗口属性；targetOrigin 不可设为 '*'，须精确指定源；监听 message 需在 DOM 加载后，发送前需校验窗口有效性。
HTML 本身不会影响跨窗口通信，也没有“HTML通信”这个独立机制；真正起作用的是 JavaScript 的 window.postMessage() —— 它是唯一安全、通用、被所有现代浏览器支持的跨窗口通信方式。别在 HTML 标签里找通信逻辑，那只会白费时间。
为什么直接操作 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() 做双向握手，导致无法确认对方是否真的收到了。
