sharedworker能显著降低服务端并发连接数，通过让同源多页面共享单个websocket实例，避免重复建连；实测某电商后台多开场景下连接数下降92%，但需严格满足https同源、worker内创建连接、clientid隔离路由等前提。
SharedWorker 本身不能直接降低服务端连接并发压力上限，但它能显著减少客户端向服务端发起的重复 WebSocket 连接数——这是缓解服务端连接压力最直接、最可控的手段。
为什么 SharedWorker 能压降服务端连接数
浏览器对同源页面默认不限制标签页数量，但每个页面若独立 new WebSocket()，就会建立一条 TCP 连接。100 个标签页 = 100 条长连接，服务端需维护 100 个 socket 文件描述符（fd）。SharedWorker 的核心价值在于：它让这 100 个页面共享 一个 WebSocket 实例。
- SharedWorker 实例在同源所有页面间唯一存在，只要至少一个页面存活，Worker 就持续运行
- WebSocket 必须在 SharedWorker 内创建（
new WebSocket()），不能由页面调用 —— 否则页面一刷新/崩溃，连接就断 - 服务端看到的只是 1 个客户端 IP + 1 个连接，而非 N 个
- 实测数据：某电商后台从单页 WebSocket 改为 SharedWorker 统一管理后，同用户多开场景下服务端并发连接数下降 92%
必须满足的硬性前提条件
SharedWorker 不是“开了就能用”的功能，任何一步不合规，整个机制会静默失效（连 onerror 都不触发）：
- 协议必须是
https://或http://localhost:port——file://、http://127.0.0.1、http://example.com全部被浏览器拒绝 - SharedWorker 脚本路径必须与页面同源（
origin完全一致），子路径不影响，如页面在/admin/dashboard，Worker 脚本可放在/js/socket-sw.js - Worker 内不能使用
localStorage、fetch、XMLHttpRequest，仅支持WebSocket、postMessage、setTimeout等基础 API - 页面首次通信必须调用
port.start()，否则 Worker 收不到消息；且需在onconnect回调中立即调用port.start()
如何避免重连雪崩和服务端频控
如果重连逻辑写在页面里，100 个标签页同时崩溃再恢复，会瞬间向服务端发出 100 次重连请求 —— 大部分服务端会直接触发限流或连接拒绝。正确做法是把全部状态控制下沉到 SharedWorker 内部：
- 连接状态（
ws.readyState）只在 Worker 内维护，页面只发指令（如{ type: "send", data: {} }） - 重连使用指数退避：
1s → 2s → 4s → 8s…，上限设为30s，用setTimeout实现（不用setInterval防止堆积） - 心跳必须由 Worker 单点发起：
setInterval(() => ws.send("ping"), 30000)，页面切后台也不中断 - 每次
ws.onopen后，主动广播一次{ type: "connected", timestamp: Date.now() }给所有页面，避免页面自行轮询判断 - 服务端需配合识别 “单客户端多标签” 场景：Worker 发送的消息里带
clientId（页面生成并首次上报），服务端据此做 topic 订阅路由，而非按连接维度广播
消息路由错乱是最隐蔽的线上故障点
SharedWorker 收到多个页面发来的 postMessage，但无法天然区分来源 —— 如果不做隔离，A 页面发的请求可能被响应给 B 页面，导致数据错乱。这不是理论风险，而是高频线上问题：
- 每个页面必须在
port.start()后，立刻发送唯一clientId（推荐用crypto.randomUUID()，不要拼接Date.now()） - Worker 内用
Map缓存clientId → port映射，并在每次port.postMessage()前校验该port是否还有效（port.closed === false） - 页面关闭前必须主动发
{ type: "disconnect", clientId: "xxx" }，Worker 清理映射；否则残留映射会导致后续消息投递失败 - 不要依赖
self.clients.matchAll()获取活跃页面 —— Chrome 返回空数组是常态，Firefox 行为不一致，不可用于生产
真正关键的不是“怎么连上”，而是“怎么确保每条消息只到该到的地方”。这个映射关系一旦出错，调试成本极高，且现象随机——有时候 A 页面收不到消息，有时候收到 B 页面的数据，必须从设计之初就强制绑定 clientId 和 port 生命周期。
