postMessage的消息接收回调属于宏任务，会在当前同步代码执行完毕且所有微任务清空后，由事件循环从宏任务队列中取出执行；其本质是浏览器规范定义的跨文档通信调度机制，与setTimeout、I/O等同级，不可被微任务插队。
postMessage 的消息接收回调属于宏任务，会在当前同步代码执行完毕、且所有微任务清空后，由事件循环从宏任务队列中取出并执行。
postMessage 回调为什么是宏任务
当调用 window.postMessage 向另一个窗口（如 iframe 或弹出窗口）发送消息时，目标窗口若注册了 message 事件监听器，该监听器的回调函数不会立即执行。浏览器内核会将该回调推入**宏任务队列（macrotask queue）**，与 setTimeout、setInterval、UI 渲染等同级调度。
这是规范定义的行为，不是实现差异——无论是否跨域，只要使用 postMessage，接收端的 message 事件处理都走宏任务路径。
它在 Event Loop 中的具体执行时机
一个典型的执行顺序如下：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 当前同步脚本运行完成
- 引擎清空本轮所有微任务（包括 Promise.then、MutationObserver 等）
- 事件循环从宏任务队列头部取出一个任务（可能是定时器、I/O 回调，也可能是 postMessage 的 message 处理）
- 执行该 message 回调
- 执行完后，再次清空微任务队列，再取下一个宏任务
注意：即使你在 Promise.then 里调用 postMessage，接收方的回调仍要等到下一轮宏任务才执行，绝不会插在当前微任务中间。
实际影响和常见误区
由于是宏任务，message 回调的执行有明确延迟特征：
- 不能保证“立刻响应”——哪怕主线程空闲，也要排队等微任务全部跑完
- 连续多次
postMessage会产生多个独立宏任务，按发送顺序排队，不会合并或去重 - 如果主线程被长时间同步代码阻塞（例如
while(Date.now() ），所有 pending 的 message 回调都会积压，触发时间远晚于发送时刻 - 跨域与否不影响任务类型，只影响
event.source和event.origin的可读性
对比 MessageChannel 更细粒度的控制
如果你需要更及时、更可控的跨窗口通信，MessageChannel 是更好的选择：
- 它的
port.onmessage回调同样是宏任务，但调度优先级略高（部分浏览器中比 postMessage 更早入队） - 支持多对一/一对多通信，且端口可传递，适合复杂通信场景
- 但本质上仍是宏任务，不改变“同步→微任务→宏任务”的基本节奏
