HTML通信不依赖跨窗口，但跨窗口是最典型场景；同页面可用postMessage、BroadcastChannel、localStorage+storage事件或直接DOM操作；跨域时postMessage是唯一原生安全方案，需严格校验targetOrigin和event.origin。
HTML 通信不依赖跨窗口，但跨窗口是它最典型、最常被需要的使用场景之一。 你完全可以在同页面内用 postMessage 做父子 iframe 通信，也可以在同源弹窗中用，甚至用 BroadcastChannel 在多个同源 tab 间传数据——这些都不算“跨窗口”，但都属于 HTML 通信范畴。
postMessage 必须有 targetWindow 才能发消息吗
是的，postMessage 是一个方法调用，必须明确作用于某个 window 对象。常见目标包括：
-
iframe.contentWindow：向同/跨域 iframe 发送 -
popupWindow（window.open()返回值）：向新打开的窗口发送 -
parent或top：在 iframe 内向父/顶层窗口发送 -
opener：在弹窗中向打开它的原窗口发送
注意：window.postMessage(...) 这种写法看似没指定目标，其实是发给当前 window 的所有监听者（比如同页面其他 iframe 或 BroadcastChannel），但实际浏览器中它只触发当前 window 的 message 事件，并不会广播到其他上下文——这点容易误解。
不跨窗口时，还有哪些 HTML 通信方式可用
当不需要跨窗口（即通信双方在同一 document 或同源多 tab），可选方案更轻量、更可控：
立即学习“前端免费学习笔记（深入）”；
-
localStorage+storage事件：适合简单状态同步，但只支持字符串，且仅限同源 tab/window -
BroadcastChannel：同源多 tab 间实时通信，支持任意可序列化数据，比postMessage更简洁，但 IE 不支持 - 直接 DOM 操作或事件派发：同源 iframe 可通过
iframe.contentDocument直接访问，无需消息机制
例如，同源 iframe 中执行 parent.customCallback(data) 是合法且高效的，没必要绕一圈 postMessage。
为什么很多人一提 HTML 通信就想到跨窗口
因为跨窗口（尤其是跨域）是唯一无法绕开间接通信机制的场景：
- 同源 iframe 可以直接读写对方 DOM 和 JS 全局变量，但跨域 iframe 被同源策略彻底阻断
- 弹窗与 opener 窗口之间，即使同源，也因 window 引用隔离而无法直接调用函数（除非显式暴露）
-
postMessage是 HTML5 唯一被所有现代浏览器实现的、原生支持跨域安全通信的 API
所以不是“HTML 通信依赖跨窗口”，而是“跨窗口（尤其跨域）迫使你必须用 HTML 通信机制”。这也是为什么文档和教程总以 iframe / popup 为示例——它们暴露了这个机制不可替代的价值。
真正容易被忽略的是：postMessage 的 targetOrigin 参数若设为 "*"，在接收端不做 event.origin 校验，就等于把通信通道对任意页面敞开；而很多线上项目只校验了发送端，却忘了在接收端也做同样检查——这会让恶意页面伪造消息注入逻辑漏洞。
