MessagePort不能直接跨域通信，它必须依附于已建立的合法跨源通道（如iframe或window.open），且需通过postMessage移交端口并显式调用port.start()才能启用双向通信。

MessagePort 能不能直接跨域通信

不能。MessagePort 本身不突破同源策略，它必须依附于已建立的跨源通道（比如 iframe 或 window.open() 后拿到的引用），且只能在双方都明确调用 postMessage() 并完成端口移交（message.port）的前提下使用。它不是独立的跨域方案，而是 postMessage 的“升级版管道”——更高效、可复用、支持多次双向通信，但前提是源头已合法跨域。

如何从 postMessage 安全移交 MessagePort

关键在 event.ports：父页向子页发消息时带上 transfer 选项，子页监听 message 事件并显式调用 event.ports[0].start() 才能启用端口。漏掉 .start()，后续所有 .postMessage() 都静默失败，无报错。

• 父页（https://a.com）发送带端口的消息：

  const iframe = document.getElementById('bot-iframe');  
  iframe.contentWindow.postMessage({ type: 'init-auth' }, 'https://b.com', [port1]);

• 子页（https://b.com）接收并激活端口：

  window.addEventListener('message', e => {  
    if (e.origin !== 'https://a.com') return;  
    if (e.data.type === 'init-auth' && e.ports.length > 0) {  
      const port = e.ports[0];  
      port.start(); // 必须调用！  
      port.postMessage({ status: 'ready' });  
    }  
  });

• 双方后续即可用该 port 双向通信，无需再校验 origin

用 MessagePort 做状态授权时容易忽略的验证点

MessagePort 不自带身份校验，授权逻辑必须由业务层补全。常见疏漏：

办公人导航

一款AI开发辅助工具，主要用于办公人导航是一个实用的办公生活导航网站，适合需要提升相关任务效率的用户。

下载

• 未验证初始 message 的 e.origin 和 e.source，导致恶意 iframe 冒充合法来源劫持端口
• 未对端口发来的每条消息做 payload 签名校验（如 JWT 或服务端签发的短期 token），仅靠端口存在就信任状态变更
• 未设置超时或心跳机制，端口长期空闲后被重用，旧授权状态未及时失效
• 未限制端口可传输的数据类型，例如允许传入 Function 或 Promise，可能引发原型污染或执行绕过

与 Token 方案相比，MessagePort 授权适合什么场景

适合「强绑定、短生命周期、高交互频次」的嵌入式授权，比如：GIS 地图插件需要实时读取主站用户权限以控制图层开关；客服机器人 iframe 需要同步登录态并响应主站菜单点击。它不适合替代 SSO 或持久化 Token，因为：

• 端口随 iframe 卸载/页面刷新而销毁，无法跨会话复用
• 不经过服务端，无法做集中吊销或审计日志
• 无法穿透多层嵌套（如 a.com → b.com → c.com），每跳都需显式移交，链路越长越脆弱

真正安全的状态授权，永远是 MessagePort + 服务端签发的短期凭证 + 每次操作级的 origin/source 校验三者缺一不可。