shared worker 不适用于千级标签页调度，因其端口数限制约100–200个且事件循环易阻塞；应改用 broadcastchannel 分片通信或 localstorage + storage 事件同步，必要时采用 sharedworker 路由隔离方案。
Shared Worker 无法支撑千级标签页的调度需求，这不是设计问题，而是浏览器底层限制问题。
Shared Worker 的连接数和消息吞吐有硬性天花板
Chrome 当前对单个 SharedWorker 实例的并发端口（MessagePort）数量设限约 100–200 个（具体取决于版本与内存压力），超过后新标签页调用 new SharedWorker() 会静默失败或抛出 DOMException: Failed to construct 'SharedWorker': Script failed to load —— 实际并非脚本加载失败，而是内核拒绝分配新 port。
更关键的是：所有端口共用一个事件循环，千个标签页同时发 port.postMessage()，极易触发消息队列积压、事件循环阻塞，表现为部分标签页收不到响应、onmessage 延迟飙升至秒级。
实操建议：
- 用
navigator.userAgent+performance.memory（如可用）粗略预估客户端承载力，超过 150 个活跃标签页时主动降级为Worker或本地调度 - 在主页面初始化时捕获
SharedWorker构造异常，并 fallback 到localStorage+storage事件做轻量同步 - 绝对不要依赖
self.clients.matchAll()做实时标签页发现——它在 Chrome 中返回空数组是常态，Firefox 行为也不一致
替代方案：用 BroadcastChannel + 状态分片实现可伸缩调度
BroadcastChannel 没有端口数限制，且各标签页独立线程收发，天然适合千级规模。但它的缺陷是不支持 request-response 模式，需自行设计应答机制。
实操建议：
- 将调度任务按业务域分片，例如用
BroadcastChannel名称区分：bc-tag-scheduler-v1、bc-tag-scheduler-v2，避免单频道消息爆炸 - 每个标签页生成唯一
requestId = crypto.randomUUID()，发送请求时附带；响应方通过同一频道回传，携带相同requestId，请求方用Map缓存 pending promise 并监听匹配响应 - 高频写操作（如标签页状态更新）改用
localStorage+storage事件，只同步变更字段（如lastActiveTime），而非全量状态
如果仍坚持用 Shared Worker，必须做三层隔离
强行上 SharedWorker 千级调度，唯一可行路径是放弃“中心化处理”，转为“中心化路由 + 分布式执行”。
实操建议：
- Worker 内不做业务逻辑，只维护一个
Map<string messageport></string>映射表，按标签页 URL hash 或 domain 分组，每组最多 50 个 port - 收到消息后，根据
origin或自定义 header 字段路由到对应分组，再由该分组内随机一个 port 转发给目标标签页（需标签页暴露window.__tagHandler全局函数） - Worker 自身禁用
fetch、indexedDB等耗时 API，所有 IO 操作透传给发起标签页执行，Worker 只做低开销字符串解析与转发
真正卡住多数人的不是代码怎么写，而是没意识到 SharedWorker 的 self.clients 在跨域 iframe、PWA 安装态、隐私模式下行为完全不可靠——哪怕你把调度逻辑写得再精巧，连端口都连不上，整个架构就塌在第一层。先跑通 200 标签页的真实压测，再谈千级。
