window.postMessage()是唯一通用且安全的跨窗口通信方式；它属JavaScript API，需指定targetOrigin校验origin，支持跨源通信，但要求发送前检查窗口状态、加载完成及消息唯一性。
HTML 通信本身不能直接解决跨窗口通信问题，真正起作用的是浏览器提供的 window.postMessage() API —— 它是 HTML5 标准的一部分，但属于 JavaScript 运行时能力，不是 HTML 标签或属性能完成的。
为什么 <iframe> 或普通 HTML 页面打不开跨窗口通信
HTML 是静态标记语言，不带执行逻辑。即使你写 <iframe src="other.html"> 或用 window.open() 打开新窗口，两个页面默认完全隔离：DOM 不互通、变量不共享、事件不穿透。没有 JS 参与，连“通信”这个动作都触发不了。
常见错误现象：
- 在子窗口里直接访问
opener.document报Blocked a frame with origin ... from accessing a cross-origin frame - 试图用
localStorage同步状态，但没监听storage事件，或跨域时根本读不到 - 把消息写在 URL 参数里（如
popup.html?msg=ok），但只适用于单次、低频、无状态的简单传递
window.postMessage() 是唯一通用且安全的跨窗口通信方式
它专为跨源（cross-origin）和同源（same-origin）窗口/iframe 设计，强制要求指定目标源（targetOrigin），避免消息被恶意窗口截获。
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
实操要点：
- 发送方必须调用
otherWindow.postMessage(data, targetOrigin)，其中otherWindow是window.open()返回值或iframe.contentWindow - 接收方必须监听
window.addEventListener('message', handler)，并在 handler 中校验event.origin是否可信 -
targetOrigin别偷懒写'*'，生产环境应明确指定协议+域名+端口，比如'https://app.example.com' - 传递的数据会自动序列化（仅支持可结构化克隆的对象），函数、DOM 节点、undefined 会被丢弃
示例（父窗口发消息给子窗口）：
const popup = window.open('/popup.html');
popup.postMessage({ type: 'INIT', token: 'abc123' }, 'https://app.example.com');
跨窗口通信容易被忽略的边界情况
很多问题不是 API 用错，而是场景没理清：
- 子窗口关闭后，父窗口仍尝试
popup.postMessage()→ 触发TypeError: Window is closed，需加if (popup && !popup.closed)判断 - iframe 加载未完成就发消息 →
contentWindow为 null，应在iframe.onload后操作 - 同一页面多个 iframe 使用相同
postMessage类型，但没加唯一id字段区分，导致消息错乱 - 移动端 Safari 对
postMessage在后台标签页中可能延迟或丢弃，敏感操作建议加超时重试
跨窗口通信的核心从来不是“怎么写 HTML”，而是“谁在什么时候、向谁、用什么格式、带什么权限发消息”。postMessage 的机制简单，但校验、容错、生命周期管理这些细节，才是实际项目里卡住人的地方。
