BroadcastChannel 不能配合 MessagePort 直接使用，因其依赖结构化克隆算法，而 MessagePort 不可复制；正确方案是 BroadcastChannel 仅广播轻量信号，再通过 SharedWorker 或 MessageChannel 建立专属 MessagePort 进行数据传输。
不能配合
直接使用——这是硬性限制，不是配置或写法问题。强行传
会立刻抛出
错误，所有尝试绕过结构化克隆的方案都会失败。
为什么 BroadcastChannel.postMessage() 会拒绝 MessagePort
浏览器在底层用结构化克隆算法（Structured Clone Algorithm）序列化
的数据，而
是有状态、不可复制的通信端点。它绑定到特定的 JS 执行上下文和底层 IPC 通道，无法安全“拷贝”或“广播”。
常见错误现象：
控制台直接报错：
哪怕只在对象里嵌套一个
字段（如
），整个
调用就会中断
该限制与浏览器版本无关，Chrome、Firefox、Edge 全部一致执行
真正可行的分层调度架构
想实现“一个标签页调度、多个标签页执行并回传结果”的异步任务分发，必须拆成两层：轻量通知 + 独立通道。
正确流程：
只负责广播信号，例如：
接收方标签页收到后，不等待、不轮询，立即主动发起连接请求（可通过
、预置
、或更可靠的
）
调度页创建
，把
通过
或
发过去，并传入
转移列表
后续所有任务参数、心跳、进度、结果全部走这个专属
，不走广播
关键点：广播只是“敲门”，不是“送货”。门开了，再换专用物流通道。
SharedWorker 是最稳的中间层选择
如果你需要长期维持任务队列、空闲 worker 发现、端口中转能力，
比纯
更合适——它天然支持多页面连接、可维护内存状态、且能安全转移
。
实操要点：
调度页调用：
收到后检查哪个连接的标签页处于空闲状态（比如维护一个
）
选中目标后，用
把新
转移过去
兼容性足够：Chrome 20+、Firefox 55+、Edge 79+，无需 polyfill
注意：不要在
里做重计算，它只做路由和状态协调；真正耗时任务仍交给各标签页的主线程或
执行。
容易被忽略的边界情况
实际部署时，以下几点常被跳过，但直接影响稳定性：
每个
实例必须在页面卸载前显式调用
，否则可能泄漏内存或触发重复监听
用
时，要监听
和
异常，防止连接丢失后任务卡死
一旦 transfer 完成，原页面的
就失效，不能再调用
，否则报
广播消息无序、无 ACK，不能用于要求严格顺序或可靠投递的场景（比如金融类操作）
复杂点不在“怎么连”，而在“连上之后怎么管”——连接生命周期、任务超时、worker 崩溃恢复、重复 claim 防御，这些才是真活儿。
BroadcastChannelMessagePortportDATA_CLONE_ERRpostMessage()MessagePortUncaught DOMException: Failed to execute 'postMessage' on 'BroadcastChannel': TypeError: An object could not be cloned.port{ type: 'assign', port }postMessage()BroadcastChannel{ type: 'TASK_AVAILABLE', taskId: 't-456', method: 'compressVideo', args: ['/tmp/a.mp4'] }window.openeriframeSharedWorkerMessageChannelport2window.postMessage()SharedWorker.port.postMessage()[port2]MessagePortSharedWorkerBroadcastChannelMessagePortsharedWorker.port.postMessage({ type: 'CLAIM_TASK', taskId: 't-456' })SharedWorkerMapclient.postMessage({ type: 'ASSIGN_TASK', payload }, [taskPort])MessagePortSharedWorkerWorkerBroadcastChannel.close()SharedWorkerworker.onerrorself.onconnectMessagePortport1.postMessage()InvalidStateError