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 不自带身份校验，授权逻辑必须由业务层补全。常见疏漏：
- 未验证初始
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 校验三者缺一不可。
