多页面WebSocket连接复用：SharedWorker与localStorage降级方案

1. 问题的本质：组件复用在“两个页面”之间为什么失效

先说结论：组件复用方案解决的是单页面内多个组件共享连接的问题，而“两个页面复用一个WebSocket”根本上是跨JavaScript运行环境的连接共享，单靠组件复用解决不了。

我做项目时遇到过这样一个场景：后台管理系统的A页面是实时设备监控面板，B页面是设备详情页，两个页面都挂着同一个WebSocket，推送设备状态、报警信息。刚开始图省事，直接在组件里各建各的连接，结果一打开第二个页面，服务端日志里就多出一条连接，页面切换多了以后，服务端连接数直接翻了一倍。更难受的是，部分云网关服务对单用户并发WebSocket数量有限制，连接一多就踢掉先前的连接，两台页面之间开始互相“挤下线”。

于是我开始找方案。网上搜“WebSocket复用”，跳出来的大多是“组件内部做一个模块级单例，多个组件调用同一个连接实例”，这类文章非常多。它的实现思路是：在模块顶层定义一个全局连接对象，任何组件加载这个模块时拿到的是同一个引用，连接只建立一次。这在单页应用里没问题，因为所有组件跑在同一个JavaScript上下文里，内存共享，单例确实有效。但一旦跨页面，这个方案就不好使了，原因是：

• 浏览器每个标签页、窗口有独立的JavaScript执行环境，内存、变量、单例对象完全隔离；
• A页面里建立的WebSocket连接，B页面拿不到这个连接对象的引用；
• 两个页面各自执行模块代码时，“全局单例”其实各有一份，等于又建了一条连接。

所以，要解决跨页面的连接复用，必须换一个思路：把连接的生命周期从页面里抽出来，放到一个所有页面都能访问到的共享环境里。浏览器提供的可行方案有两个层次：一个是官方设计的SharedWorker，另一个是借助localStorage + storage事件的降级方案。往下我会把两条路线的实现细节、选型理由、踩坑过程全部拆开讲。

2. SharedWorker方案：把WebSocket连接放到浏览器级共享环境

2.1 为什么SharedWorker是这一类问题的最优解

SharedWorker是HTML5里定义的“共享Worker”，和普通Web Worker的差别在于：普通Worker只能被创建它的页面使用，而SharedWorker可以被同一浏览器实例下、同一来源下的多个页面共享。它天然就是为“多页面共享计算资源”这种场景设计的。

用它托管WebSocket连接，核心逻辑就是：

1. WebSocket生命周期由SharedWorker内部维护，连接只建立一次；
2. 所有页面通过new SharedWorker(scriptURL)获取同一个Worker实例；
3. 页面和Worker之间通过postMessage收发消息；
4. 服务端推送到Worker的消息，由Worker广播给所有已连接的页面。

在浏览器实现上，SharedWorker的实例和脚本运行环境是全局唯一的。第一个页面创建SharedWorker时，浏览器启动Worker线程；后续其他页面再执行new SharedWorker(同一个URL)时，不再创建新线程，而是直接关联到已存在的Worker实例。这正好满足“多个页面共享同一个连接”的需求。

我把架构画成文字描述：页面A、页面B分别连接SharedWorker，SharedWorker内部持有WebSocket连接，所有页面通过消息ID区分数据来源，Worker定期发送心跳保活。这样页面A、B不需要感知彼此的存在，只需要和Worker通信。

2.2 SharedWorker脚本的完整实现

下面是我在实际项目里跑通的Worker脚本，管理WebSocket连接、订阅页面、心跳、重连都包含在里面。

javascript复制// shared-worker.js
const ports = new Set();
let ws = null;
let heartbeatTimer = null;
let retryTimer = null;
let retryCount = 0;
const RECONNECT_MAX_DELAY = 30000;
const HEARTBEAT_INTERVAL = 25000;

function broadcast(type, payload) {
  const message = JSON.stringify({ type, payload });
  ports.forEach(port => port.postMessage(message));
}

function connect(url) {
  if (ws && (ws.readyState === WebSocket.OPEN || ws.readyState === WebSocket.CONNECTING)) {
    return;
  }
  ws = new WebSocket(url);

  ws.onopen = () => {
    retryCount = 0;
    broadcast('status', { state: 'open' });
    startHeartbeat();
  };

  ws.onmessage = (event) => {
    // 这里可以根据业务消息体解析，统一广播到所有页面
    broadcast('message', event.data);
  };

  ws.onclose = () => {
    broadcast('status', { state: 'closed' });
    stopHeartbeat();
    scheduleReconnect(url);
  };

  ws.onerror = () => {
    // 错误事件后一般会触发 close
    ws.close();
  };
}

function scheduleReconnect(url) {
  if (retryTimer) return;
  const delay = Math.min(1000 * Math.pow(2, retryCount), RECONNECT_MAX_DELAY);
  retryCount += 1;
  retryTimer = setTimeout(() => {
    retryTimer = null;
    connect(url);
  }, delay);
}

function startHeartbeat() {
  stopHeartbeat();
  heartbeatTimer = setInterval(() => {
    if (ws && ws.readyState === WebSocket.OPEN) {
      ws.send(JSON.stringify({ type: 'ping' }));
    }
  }, HEARTBEAT_INTERVAL);
}

function stopHeartbeat() {
  if (heartbeatTimer) {
    clearInterval(heartbeatTimer);
    heartbeatTimer = null;
  }
}

// SharedWorker 入口：处理页面连接
self.onconnect = (event) => {
  const port = event.ports[0];
  ports.add(port);

  port.onmessage = (messageEvent) => {
    const data = messageEvent.data;
    if (!data || typeof data !== 'object') return;

    switch (data.type) {
      case 'connect':
        // 页面首次通知Worker建立连接
        if (!ws || ws.readyState === WebSocket.CLOSED) {
          connect(data.url);
        }
        break;

      case 'send':
        if (ws && ws.readyState === WebSocket.OPEN) {
          ws.send(data.data);
        }
        break;

      case 'close':
        // 这里只是页面主动断开，真正的连接是否关闭由Worker决定
        // 如果所有页面都关掉了，Worker会被浏览器回收
        break;

      case 'ping':
        // 页面侧可能也需要知道Worker存活状态
        port.postMessage(JSON.stringify({ type: 'status', payload: { state: 'worker-alive' } }));
        break;
    }
  };

  port.start();
};

这段代码里几个关键设计点，我单独说明一下：

• ports集合：用来记录所有已关联的页面端口。页面刷新、关闭时，对应的port会自动触发关闭事件，但Worker不会主动移除它。所以实际项目里我加了一个简单的定时清理机制：每隔一段时间检查端口连接状态，或者监听到异常后清理掉失效端口。不清理的后果是消息被广播给一个不存在的port，浏览器会报“Port is detached”之类的内部警告，倒是不会崩，但日志里看了心慌。

• 正常关闭连接的处理：代码里case 'close'我没让Worker直接关连接，而是把连接生命周期完全交给Worker自己控制。原因很现实：所有页面都关掉时，浏览器会自动终止SharedWorker线程，这时候WebSocket连接随Worker销毁而销毁，不需要手动关；但如果页面把Socket关了、Worker还活着，下次新页面打开时又得重新建连，失去了复用意义。所以除非业务上明确要求“某页面关闭后服务端必须感知到离线”，否则不建议在页面侧主动关连接。

• 心跳与断线重连：WebSocket长连接挂在后台页面时，可能因为网络切换、服务端释放等原因断开，因此Worker内部必须有心跳和断线重连。上面代码用了指数退避重连，初始1秒，最多30秒。实测下来，如果服务端在8小时内没有数据推送，直接断开连接的情况非常常见，心跳保持在20-30秒一次比较稳妥。

2.3 页面侧怎么调用SharedWorker

页面侧封装起来也不复杂，建议统一放在一个单例模块里，避免页面里多个组件各自new SharedWorker导致重复关联。我这里写了一个通用的sharedSocket.js：

javascript复制// shared-socket.js
let worker = null;
const listeners = new Set();
let connectionState = 'idle';

function getWorker() {
  if (worker) return worker;
  worker = new SharedWorker('/shared-worker.js');
  worker.port.onmessage = (event) => {
    const data = typeof event.data === 'string' ? JSON.parse(event.data) : event.data;
    const { type, payload } = data;
    if (type === 'status') {
      connectionState = payload.state;
    }
    listeners.forEach((listener) => listener(data));
  };
  worker.port.start();
  return worker;
}

export function connectSharedSocket(url) {
  const w = getWorker();
  w.port.postMessage({ type: 'connect', url });
}

export function sendSharedMessage(data) {
  const w = getWorker();
  w.port.postMessage({ type: 'send', data });
}

export function onSharedMessage(callback) {
  listeners.add(callback);
  return () => listeners.delete(callback);
}

export function getSharedState() {
  return connectionState;
}

调用方式：

javascript复制// A页面或B页面的业务代码
import { connectSharedSocket, sendSharedMessage, onSharedMessage } from './shared-socket';

// 初始化连接
connectSharedSocket('wss://api.example.com/live');

// 发送消息
sendSharedMessage(JSON.stringify({ action: 'subscribe', topic: 'device:001' }));

// 接收消息
const unsub = onSharedMessage((msg) => {
  if (msg.type === 'message') {
    console.log('实时数据:', msg.payload);
  }
});

这里有一个细节：connectSharedSocket不管当前Worker里的WebSocket是否已连接，都会向Worker发connect消息，Worker内部已经做了readyState判断，所以即使连接已存在也不会重复建立。这种“幂等连接请求”是跨页面复用连接的关键设计。

2.4 SharedWorker方案的边界与限制

SharedWorker虽然好用，但有几个明显的限制，开发前得先弄清楚：

• 兼容性：现代桌面浏览器（Chrome、Edge、Firefox、Safari）都支持SharedWorker，但iOS Safari对SharedWorker的支持始终不太稳定。如果产品必须兼容iOS上的Safari，需要准备降级方案。
• 端口生命周期：页面对SharedWorker的“关联”在页面刷新时不会立刻断开，浏览器有延迟回收机制。实测中，页面刷新后旧端口可能还存在于ports集合里，导致消息广播给失效端口，这个不影响主流程，但要在Worker里做好端口清理。
• 跨域限制：SharedWorker脚本受同源策略限制，共享范围限定在同源下的多个页面。跨子域名场景需要额外处理。

关于兼容性降级，我放在下一节详细讲。目前先假设你用的是现代桌面浏览器，后续再谈现实兼容问题。

3. 兼容降级：用localStorage事件接力WebSocket数据

3.1 localStorage方案的核心矛盾：连接属于单个页面

SharedWorker是官方给的跨页面共享方案，但在它不支持的环境里，我们只能找替代品。常见的替代思路有两个：

1. 在某个页面持有连接，其他页面通过localStorage、BroadcastChannel等跨标签页通信机制获取数据；
2. 使用BroadcastChannel直接广播数据，同时配合localStorage做状态同步。

这里有一个核心矛盾：**localStorage只能传递字符串，没法传递对象引用，更没法共享WebSocket连接对象本身。**所以“让B页面直接使用A页面的连接对象”是做不到的。我们只能退而求其次：让B页面不建立自己的连接，而是监听A页面转发过来的数据；发消息时也通过A页面代为发送。

这样一来，就必须解决两个问题：

• 谁是“主页面”？哪个页面持有真正的WebSocket连接？
• 主页面挂了、刷新了、连接断了，谁来接管？

我的实现方案分三层：选举层、连接层、转发层，往下逐一展开。

3.2 基于localStorage + storage事件的主备选举机制

选举机制的本质，是利用localStorage在同一个源下的所有标签页之间是共享的、且setItem操作是同步原子写这个特性，做一个“抢锁”过程。谁先拿到锁，谁就是主页面。

javascript复制// page-host.js
const LEADER_KEY = 'ws_leader';
const HEARTBEAT_KEY = 'ws_leader_heartbeat';
const DATA_KEY = 'ws_shared_data';
const ELECT_TIMEOUT = 3000;
const HEARTBEAT_INTERVAL = 2000;

function getLeaderId() {
  return localStorage.getItem(LEADER_KEY);
}

function isLeader() {
  const leaderId = getLeaderId();
  return leaderId === myPageId;
}

function tryBecomeLeader() {
  const currentLeader = getLeaderId();
  const heartbeat = parseInt(localStorage.getItem(HEARTBEAT_KEY) || '0', 10);
  const now = Date.now();

  // 没有主节点，或者主节点心跳超时（比如主页面被关闭/卡死）
  if (!currentLeader || now - heartbeat > 5000) {
    localStorage.setItem(LEADER_KEY, myPageId);
    localStorage.setItem(HEARTBEAT_KEY, String(Date.now()));
    return isLeader();
  }
  return false;
}

function renewHeartbeat() {
  if (isLeader()) {
    localStorage.setItem(HEARTBEAT_KEY, String(Date.now()));
  }
}

// 主页面把消息写入localStorage
function broadcastToPages(data) {
  localStorage.setItem(DATA_KEY, JSON.stringify({
    id: uuid(),
    time: Date.now(),
    data
  }));
}

// 副页面监听storage事件
window.addEventListener('storage', (e) => {
  if (e.key === DATA_KEY && e.newValue) {
    const payload = JSON.parse(e.newValue);
    handleMessage(payload.data);
  }
  if (e.key === LEADER_KEY) {
    if (e.newValue === null) {
      // 主节点消失，立即抢主
      tryBecomeLeader();
    }
  }
});

这段代码有几个细节容易被忽略：

• storage事件不会在写入数据的那个页面触发。所以主页面自己产生的数据，除了写入localStorage外，还要在本地直接调用一次handleMessage，否则主页面会丢消息。这是一个非常容易踩的坑，很多人第一次写localStorage方案，就会发现在主页面收不到自己“广播”出去的消息。
• 心跳超时时间（5秒）不能设得太短，否则页面短暂卡顿（主线程占用）就会导致心跳没更新，其他页面误以为主节点挂了，触发抢主，导致两个页面同时去建连接。我实测中，Chrome里主页面执行大段同步JS时，定时器会被推迟，心跳延迟几十毫秒甚至几百毫秒都可能。设5秒比较稳。
• 当主页面被正常关闭时，它的beforeunload里要清理leader记录，让副页面能快速接管。但浏览器崩溃、断电这类场景下beforeunload不触发，所以心跳过期检测机制是必要的兜底。

3.3 页面接管与连接重建的完整流程

副页面接管连接的过程，本质上是一条完整的链路：

1. 副页面通过storage事件或定时检查，发现LEADER_KEY被清除或心跳超过5秒；
2. 副页面调用tryBecomeLeader()，写入自己的页面ID；
3. 如果写入成功，说明抢主成功，副页面自己创建一个新的WebSocket连接；
4. 连接建立后，副页面进入心跳发送循环，开始扮演主页面角色；
5. 原主页面若只是临时卡顿、实际还活着，这时它发现自己不再是leader了，需要主动断开原本的连接（或者至少把自己的身份降级为副页面），避免两个WebSocket同时存在。

这个“主动断开原连接”很关键，否则会出现“双主双连接”的情况。我加上一个检测函数：

javascript复制setInterval(() => {
  const leaderId = getLeaderId();
  if (leaderId && leaderId !== myPageId) {
    // 我已经不是主页面了，断开本地WebSocket
    if (ws) {
      ws.close();
      ws = null;
    }
  }
}, 1000);

从实际工程角度看，localStorage方案的问题在于数据量。每条推送数据都写一次localStorage，如果服务端每秒推送几十条数据，localStorage的写入性能会成为瓶颈（通常限制在5MB左右，写入频繁还会带来性能压力）。所以我把这个方案定性为“降级方案”，只适配两个页面、低频推送的场景。数据量大、多页面场景，还是优先用SharedWorker。

还有一种混合方案：在不支持SharedWorker的环境下使用Web Storage事件，在支持的环境下直接走SharedWorker。前端可以做一个特性检测：

javascript复制function detectSharedWorkerSupport() {
  return typeof SharedWorker !== 'undefined' &&
         /Safari/.test(navigator.userAgent) === false;
}

注意Safari这里我不仅要检测变量存在，还要排除移动端Safari的不可靠实现，具体看产品兼容目标。我建议桌面端优先SharedWorker，移动端直接走localStorage降级方案，保证行为一致。

4. 连接代理层设计：把复用逻辑封装成对业务透明的模块

4.1 业务页面不该感知“复用”的存在

不管是SharedWorker还是localStorage接管方案，对业务页面来说，它们只关心一件事：我调一个方法，给我一个看起来像WebSocket的东西就行。因此我把整个复用逻辑封装成一层“连接代理”，暴露一个类似WebSocket的接口。

这个代理层做的事情，就是根据当前环境自动选择底层实现：

4.2 消息编号与重复消息过滤

前面提到，localStorage方案存在“主页面本地处理一次 + 存储事件触发一次”的重复投递风险。SharedWorker方案虽然不会这样，但如果你做了连接重建、把旧数据重新同步一遍，也可能产生重复消息。

所以代理层里我加了一个简单的去重机制：给每条推送消息生成全局唯一的消息ID，业务层用Set保存最近处理过的ID。做法如下：

javascript复制const recentIds = new Set();
const MAX_CACHE_SIZE = 1000;

function handleIncoming(payload) {
  if (!payload.id) {
    // 没有ID的消息视为业务层自定义消息，直接交付
    dispatch(payload);
    return;
  }
  if (recentIds.has(payload.id)) {
    return;
  }
  recentIds.add(payload.id);
  if (recentIds.size > MAX_CACHE_SIZE) {
    // 只保留最近一批ID，防止内存无限增长
    const first = recentIds.values().next().value;
    recentIds.delete(first);
  }
  dispatch(payload);
}

去重Cache不能太大，否则长时间运行的内存占用难控制。1000条上限对大多数WebSocket推送场景足够了，万一真的超过1000条，最早的消息ID被淘汰，最坏情况是旧消息重复投递一次，业务侧做幂等就可以规避。

4.3 连接状态的同步与页面上的展示

两个页面复用一个连接，还有一个容易被忽视的问题：页面需要展示连接状态（已连接、连接中、断开、重连中）。如果各页面“自报状态”，那么A页面显示已连接、B页面显示正在重连，体验会非常奇怪。

SharedWorker方案里，Worker广播status消息，所有页面可以实时同步状态。localStorage方案里，主页面需要把连接状态写入localStorage，副页面监听变化来同步展示。

我在代理层里加了一个简易的状态机：

javascript复制const stateMachine = {
  idle: { start: 'connecting', fail: 'idle' },
  connecting: { success: 'open', fail: 'reconnecting' },
  open: { close: 'closed', fail: 'reconnecting' },
  reconnecting: { success: 'open', fail: 'reconnecting' },
  closed: { start: 'connecting' }
};

每个状态变化都通过代理层广播出去，页面上的状态指示器统一订阅这个状态流。这样不管底层是用SharedWorker还是localStorage，页面上看到的状态永远是一致的。

5. 实测中的坑：连接风暴、僵尸Worker与消息丢失

5.1 多页面同时断线导致的重连风暴

SharedWorker方案下，重连风暴本来不应该发生——因为只有一个连接，只有一个重连循环。但我在调试localStorage方案时，确实遇到过一次“多页面同时重连”的情况：

当时是服务端发了一次全量推送，所有页面同时收到连接关闭通知，副页面各自检测到心跳超时、开始抢主。抢主过程本身有原子性，只有一个页面会胜利，但失败页面没有立即停止自己的重连尝试，导致短暂的“并行连接窗口”。后来我在tryBecomeLeader()失败后，加了一个保护逻辑：只有当前leader身份确认后，才真正执行new WebSocket(url)，其他页面一律等待leader广播。

一句话总结：**抢主和建连是两个动作，不能放在同一个事件循环里直接执行。**抢主成功，才能建连；没抢到，就只能等待。

5.2 SharedWorker在页面刷新时的僵尸端口

SharedWorker里最容易忽视的问题就是僵尸端口。我在开发时反复遇到一个现象：页面刷新后，服务端明明还在收到心跳，说明Worker还活着，但新页面里port.onmessage一直接不到消息。

排查发现，刷新前页面关联的port还残留在Worker的ports集合里，浏览器没有立刻触发onclose。Worker广播消息时，会给所有端口都发送一份，包括那个已经失效的旧端口，而旧端口的消息触发了异常，导致Worker内部逻辑卡住。更隐蔽的是，如果广播用的是synchronous postMessage，一个失效端口就可能阻塞整个广播。

解决办法是在Worker内部定期清理无效端口，并且给每条广播消息包裹一个try/catch：

javascript复制function broadcast(type, payload) {
  const message = JSON.stringify({ type, payload });
  ports.forEach((port) => {
    try {
      port.postMessage(message);
    } catch (e) {
      ports.delete(port);
    }
  });
}

另外，在页面侧beforeunload时主动调用port.close()，能有效减少僵尸端口残留的窗口期。

5.3 消息时序与同步问题

两个页面复用一个连接后，消息的“归属”可能会造成混乱。比如A页面发起了一条subscribe指令，服务端推送过来的数据，SharedWorker会广播给所有页面，B页面也会收到。如果服务端没有在消息里标明订阅者，B页面就会收到一堆不相关的数据。

这个问题在业务实现时务必考虑。我的经验是：把“连接级消息”和“页面级消息”分开处理。连接级消息（认证、心跳、订阅关系）由Worker统一处理，不直接广播给业务层；页面级消息（设备状态、报警事件）才广播给所有页面。如果业务确实需要“某个页面发起的订阅只推给那个页面”，那么消息体里必须携带一个requestId，Worker根据requestId做定向回传，而不是全局广播。

5.4 什么时候不该用这个方案

最后说说反例。连接复用不是万能的，有些场景强制复用反而会引入新问题：

• 每个页面使用不同账号登录：比如一个浏览器里两个标签页分别登录不同账号，各页面必须维护各自的连接，这时候复用连接会导致数据串号；
• 服务端推送依赖页面级会话状态：比如需要把连接绑定到页面级Token，Token过期时需要单独断开某页面的连接，复用会让连接级和页面级状态耦合在一起；
• 页面之间不需要共享数据，且数据量巨大：每个页面独立连接虽然消耗更多资源，但架构简单、故障域隔离，有时候“回归简单”反而更可靠。

所以我给团队的结论是：用户在同一个系统里开多个页面、看同一类数据、共享同一账号场景，优先考虑连接复用；有明显隔离需求的场景，宁可多建几条连接，也不要强行复用。

实际项目里，我最终同时实现了SharedWorker和localStorage两个方案，通过代理层做自动切换。桌面端（Chrome、Edge）走SharedWorker，移动端和iOS Safari走localStorage降级，实测下来整体稳定。如果你只是普通后台管理系统，数据推送频率不算高，其实localStorage方案已经够用；但如果你要处理高频率实时数据，并且产品面向的是桌面浏览器，优先把SharedWorker方案做起来，这个投入是值得的。