broadcastchannel 无法传递 messageport，因其依赖结构化克隆算法，而 messageport 含内部状态不可序列化；可行方案是广播轻量信号后通过 sharedworker 或 messagechannel 建立点对点通道传输任务数据。
BroadcastChannel 无法直接传递 MessagePort，强行调用 bc.postMessage({ port }) 会立即抛出 DATA_CLONE_ERR 错误——这不是兼容性问题，而是浏览器的硬性限制。
为什么 BroadcastChannel.postMessage() 会拒绝 MessagePort
BroadcastChannel 底层依赖结构化克隆算法（Structured Clone Algorithm），只允许传输可序列化的值：基本类型、普通对象、ArrayBuffer、TypedArray 等。而 MessagePort 是有状态的通信端点，包含内部引用和事件监听器，无法被安全复制或转移。
常见错误现象：
- 控制台报错：
Uncaught DOMException: Failed to execute 'postMessage' on 'BroadcastChannel': TypeError: An object could not be cloned. - 代码静默失败（部分旧版 Chromium 表现为无提示丢弃）
- 误以为是跨域或命名不一致导致，实际跟频道名完全无关
真正可行的任务分发流程：广播信号 + 独立建连
想让一个页面作为调度中心、其他页面作为执行者，必须拆成两步走：先用 BroadcastChannel 广播轻量信号，再用独立机制建立点对点通道传任务数据和结果。
- 调度页发送：
bc.postMessage({ type: 'TASK_AVAILABLE', taskId: 't-42', method: 'compressVideo', args: ['input.mp4'] }) - 空闲 worker 页收到后，主动发起连接请求（例如通过
window.open()回调、预置iframe或调用SharedWorker） - 调度页创建
MessageChannel，把port2通过window.postMessage()或SharedWorker.port.postMessage()发给目标页（需在transfer参数中显式传入） - 后续所有任务参数、进度、返回值都走该
port1/port2双向通道，不再经过广播
SharedWorker 是最稳的中间层选择
相比纯前端轮询或 iframe 中转，SharedWorker 天然适配这种架构：它能长期驻留、维护 worker 页面列表、支持端口转移，并且兼容性已足够（Chrome 20+、Firefox 55+、Edge 79+）。
关键实操点：
- 调度页调用
sharedWorker.port.postMessage({ type: 'CLAIM_TASK', taskId: 't-42' }) - Worker 内用
Map记录各页面端口，检查是否有空闲页，再调用port.postMessage({ type: 'ASSIGN_TASK', payload }, [taskPort])（注意[taskPort]必须出现在 transfer 列表） - worker 页收到带
port的消息后，立刻port.onmessage监听并port.start()，否则消息会被丢弃 - 页面关闭时务必
port.close()，否则 SharedWorker 可能持续持有失效端口，引发内存泄漏
容易被忽略的生命周期细节
整个链路里最脆弱的不是通信本身，而是端口和频道的销毁时机。
-
BroadcastChannel实例必须在beforeunload阶段调用bc.close()，否则页面卸载后仍可能触发onmessage（尤其在快速切换标签时） -
MessagePort一旦关闭，另一端再postMessage()就会静默失败，建议封装一层带port.postMessage && !port.closed检查的发送函数 - SharedWorker 启动失败（如被禁用或不支持）时，应降级到
localStorage+storage事件模拟状态同步，而非直接报错中断 - 每个
BroadcastChannel名称必须全局唯一，比如加版本前缀app-v3-task-bc，避免第三方库冲突
