BroadcastChannel 不能传输 MessagePort，因结构化克隆算法禁止复制有状态端点，必抛 DATA_CLONE_ERR；正确方案是用广播触发信号，再通过独立 MessagePort 或 SharedWorker 转移任务数据。
BroadcastChannel 不能配合 MessagePort 直接使用——这是硬性限制，不是配置或写法问题。强行传 port 会立刻抛出 DATA_CLONE_ERR，根本走不到调度逻辑。
为什么 BroadcastChannel.postMessage() 会报 DATA_CLONE_ERR
浏览器在底层用结构化克隆算法（Structured Clone Algorithm）序列化所有 postMessage() 数据。MessagePort 是有状态、不可复制的通信端点，它绑定具体执行上下文，无法被安全克隆或转移。
常见错误现象：Uncaught DOMException: Failed to execute 'postMessage' on 'BroadcastChannel': TypeError: An object could not be cloned.
这不是兼容性问题，是规范强制禁止——Chrome、Firefox、Edge 全部一致行为。
真正能落地的任务分发架构：广播 + 点对点通道分离
核心思路是职责拆分：BroadcastChannel 只干一件事：轻量广播「任务来了」信号；真正的参数、进度、结果传输必须走独立建立的 MessagePort 通道。
- 调度页（主控标签页）调用
bc.postMessage({ type: 'TASK_AVAILABLE', taskId: 't-123', payload: { method: 'compressVideo', args: [...] } }) - 空闲 worker 标签页监听到后，不直接处理，而是主动向调度页发起连接请求（例如通过
window.opener?.postMessage()或预置SharedWorker中转） - 调度页收到请求，创建
new MessageChannel()，把port2通过window.postMessage()或SharedWorker.port.postMessage(..., [port2])安全移交 - 后续所有任务数据都走这个专属
port1/port2，不再经过广播频道
用 SharedWorker 替代纯 BroadcastChannel 更可靠
如果调度逻辑较重（比如要维护 worker 状态、负载均衡、失败重试），SharedWorker 是更自然的选择——它本身支持多页面连接、可持状态、能中转 MessagePort，且兼容性已足够好（Chrome 20+、Firefox 55+、Edge 79+）。
- 调度页发
sharedWorker.port.postMessage({ type: 'CLAIM_TASK', taskId: 't-123' }) -
SharedWorker内检查哪个页面 port 处于空闲，再调用port.postMessage({ type: 'ASSIGN_TASK', data: ... }, [taskPort])把新MessagePort转移过去 - worker 标签页拿到
port后，立即绑定onmessage并开始执行，结果也走该端口回传
注意：SharedWorker 的 port.postMessage() 第二个参数 [port] 必须显式传入 transfer list，否则端口不会真正移交，只会被忽略。
关键点在于：广播只是触发器，不是管道。任何试图把 MessagePort 塞进 BroadcastChannel 的方案都会在第一步就失败。调度复杂度越高，越应该放弃“广播直传”幻想，转向 SharedWorker 或 Service Worker 这类带状态的中间层。
