sharedworker 天然单线程运行，所有端口共享同一事件循环，不存在线程负载失衡；性能瓶颈源于消息路由开销、websocket发送堆积、失效port未清理及重连逻辑失控，可通过weakmap缓存、零拷贝传输、fifo队列和定时清理优化。

sharedworker 本身是单线程运行的，不存在“多个长连接 port 导致线程负载失衡”的问题——它天然只有一个执行线程，所有端口（port）通信、消息路由、心跳、重连都串行处理。所谓“负载失衡”，实际是误将 sharedworker 与多线程服务（如 envoy worker、node.js cluster）混淆了。

SharedWorker 的线程模型本质是单线程

SharedWorker 在浏览器中始终运行于**一个独立的后台线程**，无论接入 2 个还是 200 个页面（port），所有 onconnect、onmessage、WebSocket 回调都在该线程内顺序执行。它不分配子线程，也不做工作负载分片。因此：

• 不存在 CPU 核心间不均衡（比如某个 core 占满而其他 idle）
• 没有“port 绑定到不同线程”的机制，所有 port 共享同一事件循环
• 高并发消息不会引发线程争抢，但可能造成单线程阻塞（如大量同步计算或未 await 的 Promise）

真正影响性能的瓶颈点

当接入端口数显著增加（如 >50 个标签页），性能下降通常源于以下可优化环节，而非“线程失衡”：

• 消息路由开销过大：用 Map 查表时，若未缓存 port 引用或频繁遍历，O(n) 路由会拖慢主循环
• WebSocket send() 阻塞主线程：虽然 send() 是异步的，但若批量发送大消息且未节流，会堆积 microtask 队列
• 未清理失效 port：页面崩溃或强制关闭未发 disconnect，Worker 内 Map 持有已断开 port 引用，导致内存泄漏 + 路由冗余
• 重连逻辑无节制触发：指数退避未正确实现（如 setTimeout 未 clearTimeout 旧定时器），造成定时器堆积

轻量级优化建议（无需改线程模型）

针对高 port 数场景，聚焦提升单线程吞吐效率：

• 在 onconnect 中立即调用 port.start()，避免消息积压；用 WeakMap 存储 port → clientId 映射，便于自动回收
• 对高频业务消息（如心跳响应、状态广播）使用 port.postMessage(data, transferList) 零拷贝传输 ArrayBuffer
• WebSocket 发送前做简易队列控制：用长度 ≤ 3 的 FIFO 缓冲区 + requestIdleCallback 触发 flush，防突发洪峰
• 定期（如每分钟）扫描 Map，对超时 30s 无消息的 port 主动 close 并清理，避免僵尸端口累积

Safari 或旧环境下的兼容性注意

macOS 13.3+/iOS 16.4+ 才完整支持 SharedWorker，旧版本 fallback 时若采用 BroadcastChannel + 主控页代理，才可能出现真正的“多页面竞争主控权”导致逻辑抖动——但这属于架构降级引入的问题，不是 SharedWorker 本身的负载问题。