主线程创建并托管WebSocket连接，Worker负责心跳调度、状态监控与指数退避重连，通过MessageChannel实现低延迟通信，利用Worker独立定时器保障后台心跳连续性。
Worker线程本身不能直接创建 WebSocket 实例（因为 WebSocket 构造函数在 Worker 全局作用域中不可用），所以“在 Worker 中使用 WebSocket”需要借助主线程代理或使用 SharedWorker + 主线程桥接。真正可行且稳定的方案，是让主线程管理 WebSocket 连接，Worker 负责数据处理与心跳调度，两者通过 postMessage 协同——这才是提升长连接稳定性的核心技巧。
主线程托管 WebSocket，Worker 专注心跳与状态监控
WebSocket 必须由主线程创建和维持，但连接保活、重连逻辑、超时判断等可下沉到 Worker 中统一管理，避免主线程阻塞或页面失焦导致心跳中断。
- 主线程只负责
new WebSocket(url)、监听open/message/close/error事件，并将原始消息转发给 Worker - Worker 接收主线程发来的连接状态（如
{ type: 'connected', ts: Date.now() }），启动定时心跳任务（例如每 25 秒发一次ping消息） - Worker 维护一个“最后收到消息时间戳”，若超过 45 秒无响应，主动通知主线程断开并触发重连
用 MessageChannel 实现低延迟双向通信
避免频繁使用 worker.postMessage() 传输大量数据带来的序列化开销和队列延迟。改用 MessageChannel 建立专用通道，提升心跳响应和指令同步的实时性。
- 主线程创建
const channel = new MessageChannel()，将channel.port2传给 Worker：worker.postMessage({ type: 'init', port: channel.port2 }, [channel.port2]) - Worker 保存
port并监听port.onmessage，主线程通过channel.port1直接发送心跳确认、连接异常等轻量信号 - 大数据（如业务消息体）仍走常规
postMessage，小状态信号走MessageChannel，分工明确
Worker 内实现指数退避重连策略
当连接断开后，重连不应固定间隔轮询，而应由 Worker 独立维护一套退避逻辑，减轻主线程负担，也避免多个标签页重复触发重连风暴。
立即学习“前端免费学习笔记（深入）”；
- Worker 内定义重试次数和基础延迟（如
baseDelay = 1000，最大重试 10 次） - 每次失败后延迟 =
Math.min(baseDelay * Math.pow(2, retryCount), 30000)（上限 30 秒） - Worker 在重连前向主线程发送
{ type: 'reconnect', delay: xxx }，由主线程决定是否执行（例如检查网络状态navigator.onLine）
利用 Worker 的独立计时器规避页面冻结影响
浏览器在页面后台/休眠时会限制主线程定时器精度（setTimeout 可能延迟数秒甚至被暂停），但 DedicatedWorker 的定时器不受影响，适合保障心跳连续性。
- Worker 内使用
setInterval(() => { sendPing(); }, 25000)发送心跳，即使页面切换到其他标签页或锁屏，只要 Worker 未被系统终止，定时器仍可运行 - 配合
self.onmessage接收主线程发来的“页面可见性变更”消息（如document.hidden变为 true），Worker 可临时降频心跳（如改为 60 秒），兼顾稳定性与资源节约 - 注意：Service Worker 不适用此场景（不支持
setInterval长期驻留，且无法直接通信 WebSocket）
不复杂但容易忽略：Worker 不能访问 document 或 window，所有依赖环境的判断（如网络状态、页面可见性）必须由主线程采集后主动推送；WebSocket 的二进制数据处理（如 arraybuffer）可在 Worker 中高效完成，再将解析结果发回，真正发挥多线程优势。
