postMessage本身不拖慢跨窗口通信，卡顿源于高频发送、大数据量、接收端重操作、未清理监听器等使用不当；origin填“*”不影响性能但危害安全；iframe与window.open在进程隔离和加载时机上存在差异；轻量通信需精简数据、延迟处理、校验目标及合理选型。
window.postMessage 本身不会拖慢跨窗口，卡顿从来不是通信机制的问题，而是你没管住发送频率、没校验来源、或者在接收端干了重活。
为什么 postMessage 会被误认为“拖慢窗口”
根本原因不是 postMessage 调用慢，而是它像一个快递员——派单快，但如果你让它每毫秒送一次大包裹，或者收件人拆包时直接现场造一辆车，那整个流程就卡了。
- 高频触发：比如在
input或scroll里无防抖地调用postMessage，瞬间堆积几十条消息，接收方的message事件回调来不及处理 - 数据过大：传了个未压缩的
JSON.stringify(editorState)（几 MB），序列化/反序列化吃满主线程 - 接收端同步重绘：收到消息后立刻执行
highlight()或renderTable()，而这些函数本身就要 50ms+，多个窗口同时响应就会互相挤占 - 忘记移除监听：页面卸载后
window.addEventListener('message', handler)还挂着，旧 handler 继续响应新消息，造成内存泄漏和逻辑错乱
postMessage 的 origin 参数填 “*” 会变慢吗
不会变慢，但会变危险——性能无损耗，安全有硬伤。
-
targetOrigin是纯匹配判断，开销可忽略，填"*"和填"https://a.com"在执行速度上没区别 - 但填
"*"后，任何来源窗口（包括恶意弹窗）都能往你的页面发消息，如果接收端又没做event.origin校验，就等于敞开大门收任意脚本指令 - 真实项目中应始终使用精确 origin：
"https://pay.example.com"，同域可用"/"，但别图省事写"*" - 若目标窗口源不确定（如嵌入第三方 iframe），宁可加一层白名单校验：
if (!['https://a.com', 'https://b.net'].includes(event.origin)) return;
iframe 与 window.open 的 postMessage 行为差异
底层 API 一样，但生命周期和上下文隔离程度不同，直接影响资源占用和卡顿表现。
-
window.open打开的新窗口是独立渲染进程（Chromium 下），JS 堆不共享，GC 不互相干扰；但每个窗口都运行完整前端应用时，内存翻倍是常态 -
iframe默认同进程（除非显式启用iframe[loading="lazy"]或跨域沙盒），多个 iframe 共享主线程，一个卡住，全卡住 - 向
iframe.contentWindow发消息前，必须确保 iframe 已加载完成（监听load事件），否则contentWindow为null，调用postMessage报错且静默失败 - 向
window.open返回的winRef发消息，要等winRef.location可读（即已跳转或初始页面加载完），否则同样失败
如何让跨窗口通信真正轻量
关键不是少发消息，而是让每次消息“够用、够小、够准”。
- 只传必要字段：不要传整个对象，用
{ type: 'SAVE_SUCCESS', id: 123 }替代JSON.stringify(doc) - 接收端用
requestIdleCallback延迟处理非紧急消息，避免打断用户操作：“保存成功”提示可以等 100ms 再显示 - 发送前检查目标窗口是否存活：
if (winRef && !winRef.closed) winRef.postMessage(...) - 用
Transferable传 ArrayBuffer（如二进制图片数据），避免拷贝：winRef.postMessage(data, [data.buffer]) - 对频繁通信场景（如编辑器协同），改用 SharedWorker + MessageChannel，绕过 window 对象的耦合
真正难的不是怎么发消息，而是想清楚哪条消息值得发、发给谁、以及对方收到后到底该干什么——多数卡顿，都死在这三问没答好。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
