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