broadcastchannel 不支持 messageport，因其仅允许结构化克隆数据，而 messageport 无法被序列化，强行传递会抛出 data_clone_err 错误；正确方案是用 broadcastchannel 广播任务信号，再通过 sharedworker 或 messagechannel 建立点对点通信通道。
BroadcastChannel 本身不支持 MessagePort，强行配合会失败——它只收发可结构化克隆的数据，不能传递 port 对象。
为什么 BroadcastChannel.postMessage() 不能传 MessagePort
浏览器明确禁止将 MessagePort、Window、Function 等非可克隆对象通过 BroadcastChannel.postMessage() 发送。尝试传入会直接抛出 DATA_CLONE_ERR 错误：
Uncaught DOMException: Failed to execute 'postMessage' on 'BroadcastChannel': TypeError: An object could not be cloned.
这是因为 BroadcastChannel 底层走的是跨进程消息广播机制（类似 IPC），所有数据必须经过结构化克隆算法（Structured Clone Algorithm）序列化，而 MessagePort 是有状态的通信端点，无法被安全复制或转移。
真正可行的“任务分发架构”组合方案
想实现跨标签页的任务分发（比如一个标签页作为调度中心，其他标签页作为 worker 执行任务并回传结果），必须用分层设计：用 BroadcastChannel 做轻量通知，再用独立通道（如 MessageChannel + SharedWorker 或 iframe）建立点对点连接。
-
BroadcastChannel只用于广播「任务可用」信号，例如：{ type: 'TASK_AVAILABLE', taskId: 't-123', payload: { method: 'processImage', args: [...] } } - 接收方收到后，主动发起与调度页的点对点连接（例如通过
window.open()回调、SharedWorker中转、或预置的iframe通信端口） - 调度页创建
MessageChannel，把port2通过window.postMessage()或SharedWorker.postMessage()传给目标标签页，建立专属双向通道 - 后续任务参数、进度、结果全部走该
MessagePort，避免广播污染和竞态
SharedWorker 是最贴近需求的中间层
如果你需要长期稳定的任务分发能力，SharedWorker 比纯 BroadcastChannel 更合适——它天然支持多页面连接、可维护状态、能中转 MessagePort，且兼容性足够（Chrome 20+, Firefox 55+, Edge 79+）。
关键点：
- 调度页调用
sharedWorker.port.postMessage({ type: 'CLAIM_TASK', taskId: 't-123' }) -
SharedWorker收到后检查空闲 worker 标签页，再用port.postMessage({ type: 'ASSIGN_TASK', port: taskPort }, [taskPort])把新MessagePort转移过去 - 所有任务数据、超时控制、重试逻辑都由
SharedWorker统一管理，BroadcastChannel完全不用参与
容易忽略的坑：频道名大小写与关闭时机
实际部署中高频出错的不是逻辑，而是细节：
-
BroadcastChannel的频道名严格区分大小写，'task-channel'和'Task-Channel'是两个隔离通道，务必全局统一命名 - 忘记在
beforeunload中调用channel.close()，会导致浏览器后台残留 channel 实例，下次打开页面时可能收到旧消息 - 多个标签页同时监听同一频道并调用
postMessage()，没有协调机制时容易造成任务重复抢占——必须靠SharedWorker或服务端锁来解决
真要落地任务分发，别硬套 BroadcastChannel + MessagePort，先确认是否真的需要广播层；多数场景下，SharedWorker 单独就能扛住，更稳、更可控、更容易调试。
