sharedworker是保障websocket心跳连续性的唯一可靠位置，因页面定时器在后台会失准；心跳须在worker内用setinterval发送ping并校验pong，超时未响应则主动关闭重连，且重连需指数退避、单点协调；safari旧版本存在兼容性缺陷，需ua检测并降级为broadcastchannel方案。
SharedWorker 里必须自己发 ping，不能靠页面定时器
页面切到后台或被冻结时，setInterval 和 setTimeout 会严重失准甚至暂停，导致心跳中断、服务端误判断连。SharedWorker 的 JS 执行环境独立于页面活跃状态，是唯一能保障心跳连续性的位置。
实操要点：
- 心跳必须用
setInterval(() => ws.send("ping"), 30000)写在 SharedWorker 脚本内，不能由任何页面发起 - 服务端需响应
"pong"；Worker 要记录每次发送和最后收到 pong 的时间戳 - 连续两次未在超时窗口（如 45s）内收到 pong，就主动调用
ws.close()，触发重连流程 - 避免在
onmessage或onerror回调里直接发 ping——它们不是心跳主循环，容易漏发
心跳失败后重连必须指数退避，且只由 Worker 单点执行
多个标签页如果各自重连，服务端会在几秒内收到数十个重复连接请求，极易触发限流或雪崩。SharedWorker 天然单例，是唯一能协调重连节奏的节点。
实操要点：
- 用
setTimeout实现退避（不用setInterval），防止重试队列堆积：第一次等1000ms，第二次2000ms，第三次4000ms……上限30000ms - 重连前检查
ws?.readyState，仅当为WebSocket.CLOSED或未初始化时才调用new WebSocket(url) - 重连成功后，立刻向所有已注册端口广播
{ type: "status", state: "connected" }，并重发各端口缓存的subscribe指令 - 不要在页面
useEffect或mounted钩子中写重连逻辑——那只是给单个 tab 用的，和全局心跳无关
心跳消息必须带唯一标识，否则服务端无法区分来源
单条 WebSocket 连接被多个页面复用，但服务端需要知道“这个 ping 是谁发的”，尤其当它要回 pong 给特定客户端做保活确认时。
实操要点：
- Worker 发送 ping 时不带业务数据，但建议加轻量标识字段，例如：
ws.send(JSON.stringify({ type: "ping", ts: Date.now(), from: "shared-worker" })) - 服务端收到后应原样返回
{ type: "pong", ts: ..., from: "shared-worker" }，Worker 校验from字段再更新心跳时间戳 - 不要把页面
clientId塞进 ping 消息——心跳是连接级行为，不是业务级路由，混用会导致服务端逻辑耦合过重 - 若服务端不支持自定义 ping/pong 格式，至少确保其协议层能识别并透传标准 WebSocket ping/pong 帧（多数代理和网关默认支持）
Chrome/Firefox 支持心跳，Safari 16.4+ 才可靠，旧版本必须降级
Safari 在 macOS 13.2 / iOS 16.3 及更早版本中，SharedWorker 无法维持稳定 WebSocket 连接，心跳会静默失效，且无明确错误抛出。这不是代码问题，是浏览器实现缺陷。
实操要点：
- 运行时检测：
if (!('sharedWorker' in self)) { /* fallback */ }不够，要加 UA 判断：navigator.userAgent.includes("Safari") && !navigator.userAgent.includes("Version/16.4") - 降级方案只能选 BroadcastChannel + 主控页代理：由首页建连，其他页通过
BroadcastChannel监听"ws-ready"信号，不再尝试创建 SharedWorker - 本地调试务必用
http://localhost，Safari 对file://下的 SharedWorker 完全禁用，连构造函数都不存在 - 上线前必须确认 HTTPS —— Safari 对非安全上下文的 SharedWorker 构造调用会静默失败，
onerror都不会触发
SharedWorker 的心跳能力高度依赖浏览器实现细节，尤其是 Safari 的兼容性边界非常窄。最容易被忽略的是：心跳有效性 ≠ 连接可用性——你看到 ping 发出去了、pong 收回来了，不代表服务端真的把这条连接纳入了活跃池，有些网关或负载均衡会按“最近业务消息时间”而非“心跳帧”来判断连接存活。真正在意稳定性，得和服务端协同定义保活语义。
