不用 SharedWorker 也能 P2P？用 MessageChannel 实现多标签页精准点对点通信

在构建复杂的多标签页 Web 应用（如多窗口 IDE、低延迟监控仪表盘、协作式工作台）时，标签页之间的通信性能和精准度至关重要。

通常，开发者首先会想到 SharedWorker。它作为唯一的中央线程，非常适合担任“通信网关”。然而在实际生产环境中，SharedWorker 面临着严峻的兼容性与生存挑战：

1. 兼容性断层：iOS Safari 对 SharedWorker 的支持极其不稳定，甚至在某些版本中直接不可用。
2. 隐私模式限制：在大多数浏览器的“无痕/隐私模式”下，SharedWorker 会被直接禁用。
3. 跨域/沙箱限制：在受限的 Iframe 或跨子域场景中，实例化 SharedWorker 经常触发安全报错。

如果退而求其次选择 BroadcastChannel 或 localStorage，又会引入**广播风暴（Broadcast Storm）**的问题——所有标签页都会收到冗余的广播消息，在面临高频、大数据量交互（如 Canvas 实时渲染、音视频状态同步）时，会导致明显的 CPU 占用和帧率抖动。

本文将介绍一种更优雅、高性能的替代方案：利用 ServiceWorker（或 Window Opener）作为临时“媒婆”（Broker），在两个独立标签页之间直接传递 MessagePort，建立一条绝对排他的、P2P（点对点）的双向直连通道。

核心设计思想：媒婆模式（The Matchmaker Pattern）

MessageChannel 产生的 MessagePort 是 HTML5 提供的原生双向通信管道。它的绝妙之处在于可转移性（Transferable）：你可以把管道的一端（port2）像接力棒一样发射给另一个上下文，一旦对方接收，双方就能建立起不受外界干扰的直接连接。

但问题是：在两个完全平行的标签页之间，我们无法直接调用 postMessage 转移端口，因为我们拿不到对方的 window 引用。

因此，我们需要一个双方都能触达的“媒婆”来完成端口的交接。由于 ServiceWorker 的兼容性和生命周期远比 SharedWorker 稳定，我们选择 ServiceWorker 作为这个临时媒婆。

通信建立流程

+----------+             +----------------+             +----------+
|  Tab A   |             | ServiceWorker  |             |  Tab B   |
+----------+             +----------------+             +----------+
     |                           |                           |
     | 1. 创建 MessageChannel   |                           |
     |    (port1, port2)         |                           |
     |                           |                           |
     | 2. 转移 port2 到 SW ------->                           |
     |    (携带 Target Client ID) |                           |
     |                           | 3. 将 port2 再次转移 ------>|
     |                           |    (携带 Source Client ID)|
     |                           |                           |
     |========================== Direct P2P =================|
     | 4. 双方通过 port1 <-----------------------------> port2  |
     |    直接通信，不经过 SW                                  |

一旦第 3 步完成，ServiceWorker 的使命就结束了。后续 Tab A 和 Tab B 的高频通信是纯内存级别的直接调用，零序列化损耗，不经过任何中间件，性能达到极致。

核心代码实现

下面我们编写一个完整的、生产可用的连接器。它包含两部分：ServiceWorker 端的“中转路由器”和客户端的“连接 SDK”。

1. 编写 ServiceWorker 媒婆端 (sw.js)

ServiceWorker 只需要负责一件事：收到 A 端的连接请求和 MessagePort，将其精准投递给 B 端的 Client。

// sw.js
self.addEventListener('install', (event) => {
  self.skipWaiting();
});

self.addEventListener('activate', (event) => {
  event.waitUntil(self.clients.claim());
});

// 监听客户端发送的端口交换请求
self.addEventListener('message', async (event) => {
  const { data, ports, source } = event;
  if (!ports || ports.length === 0) return;

  const port = ports[0];

  if (data.type === 'P2P_CONNECT_REQ') {
    const targetClientId = data.targetClientId;
    const sourceClientId = source.id;

    try {
      // 获取目标标签页的 Client 实例
      const targetClient = await self.clients.get(targetClientId);
      
      if (targetClient) {
        // 将 port2 和发送方的 ID 一起转移给目标标签页
        targetClient.postMessage({
          type: 'P2P_INCOMING_CONN',
          sourceClientId: sourceClientId,
          payload: data.payload // 携带自定义初始化数据
        }, [port]);
      } else {
        // 目标不存在，通知发送方
        port.postMessage({ type: 'P2P_ERROR', reason: 'Target client offline' });
        port.close();
      }
    } catch (err) {
      port.postMessage({ type: 'P2P_ERROR', reason: err.message });
      port.close();
    }
  }
});

2. 封装客户端 SDK (P2PConnector.js)

在客户端，我们需要处理端口的创建、转移的申请、接收以及连接断开的生命周期管理。

// P2PConnector.js
export class P2PConnector {
  constructor() {
    this.clientId = null;
    this.activeConnections = new Map(); // targetClientId -> MessagePort
    this.onConnectionHandler = null;

    this._init();
  }

  async _init() {
    if (!('serviceWorker' in navigator)) {
      throw new Error('ServiceWorker not supported in this browser.');
    }

    // 等待 SW 准备就绪并获取当前 Client ID
    const registration = await navigator.serviceWorker.ready;
    
    // 监听来自 SW 的端口投递
    navigator.serviceWorker.addEventListener('message', (event) => {
      const { data, ports } = event;
      if (data.type === 'P2P_INCOMING_CONN') {
        const sourceClientId = data.sourceClientId;
        const incomingPort = ports[0];
        
        this._setupPort(sourceClientId, incomingPort);
        
        if (this.onConnectionHandler) {
          this.onConnectionHandler({
            clientId: sourceClientId,
            port: incomingPort,
            payload: data.payload
          });
        }
      }
    });

    // 获取自身 Client ID 的辅助方法
    this.clientId = await this._getSelfClientId();
  }

  async _getSelfClientId() {
    // 触发 SW 激活并返回当前 Client ID
    const clients = await window.caches.keys(); // 仅用于确保上下文
    // 通过 sw 渠道或者直接从当前 controller 获取
    return new Promise((resolve) => {
      const channel = new MessageChannel();
      channel.port1.onmessage = (e) => resolve(e.data.clientId);
      // 向 SW 发送 Ping 获取自身 ID
      navigator.serviceWorker.controller.postMessage({ type: 'GET_MY_ID' }, [channel.port2]);
    });
  }

  /**
   * 向指定的目标标签页发起直连
   * @param {string} targetClientId 目标标签页的 ServiceWorker Client ID
   * @param {any} payload 自定义握手数据
   */
  async connectTo(targetClientId, payload = {}) {
    if (this.activeConnections.has(targetClientId)) {
      return this.activeConnections.get(targetClientId);
    }

    const { port1, port2 } = new MessageChannel();

    // 将 port2 转移给 SW，要求其中转给目标 Client
    navigator.serviceWorker.controller.postMessage({
      type: 'P2P_CONNECT_REQ',
      targetClientId: targetClientId,
      payload: payload
    }, [port2]);

    this._setupPort(targetClientId, port1);
    return port1;
  }

  _setupPort(clientId, port) {
    this.activeConnections.set(clientId, port);

    // 开启端口监听（重要：必须调用 start() 才能开始接收消息）
    port.start();

    // 自动清理机制：监听连接异常或关闭
    port.addEventListener('messageerror', () => this.disconnect(clientId));
  }

  /**
   * 监听外部主动建立的连接
   */
  onConnection(callback) {
    this.onConnectionHandler = callback;
  }

  disconnect(clientId) {
    const port = this.activeConnections.get(clientId);
    if (port) {
      port.close();
      this.activeConnections.delete(clientId);
      console.log(`[P2P] Connection with ${clientId} closed.`);
    }
  }
}

补充说明：为了让 GET_MY_ID 正常工作，你需要在 sw.js 的 message 监听器中追加一个简单的逻辑：如果 data.type === 'GET_MY_ID'，则通过投递过来的 ports[0].postMessage({ clientId: event.source.id }) 返回其 ID。

真实应用场景演练

假设我们现在有一个主控制台页面（Console）和一个数据可视化大屏页面（Dashboard），我们要让它们建立极致低延迟的 P2P 管道。

步骤 1：主控制台发起连接

主控制台需要先获取大屏页面的 clientId。这可以通过 ServiceWorker 提供的 self.clients.matchAll() 广播获取，或者通过后端的 WebSocket 路由。获取到 ID 后，直接发起连接：

import { P2PConnector } from './P2PConnector.js';

const connector = new P2PConnector();

// 假设我们通过某种媒介（如 BroadcastChannel）拿到了大屏页面的 targetClientId
const targetClientId = "xxxx-dashboard-client-id"; 

btnConnect.addEventListener('click', async () => {
  const port = await connector.connectTo(targetClientId, { role: 'controller' });
  
  // 开始发送高频数据
  setInterval(() => {
    port.postMessage({
      type: 'RENDER_DATA',
      timestamp: performance.now(),
      matrix: [/* 模拟大量物理引擎计算数据 */]
    });
  }, 16); // ~60fps 频率发送

  port.onmessage = (event) => {
    console.log('收到大屏页面的回执:', event.data);
  };
});

步骤 2：大屏页面被动接收并响应

大屏页面只需要注册连接监听器，一旦有通道被“媒婆”送上门，立刻接管并开始渲染：

import { P2PConnector } from './P2PConnector.js';

const connector = new P2PConnector();

connector.onConnection(({ clientId, port, payload }) => {
  console.log(`成功与主控端 ${clientId} 建立 P2P 直连，携带参数:`, payload);

  port.onmessage = (event) => {
    if (event.data.type === 'RENDER_DATA') {
      // 极致性能：直接送入 WebGL 渲染循环
      renderCanvas(event.data.matrix);
      
      // 快速回执
      port.postMessage({ type: 'ACK', status: 'rendered' });
    }
  };
});

核心设计坑点与避坑指南

在生产环境中落地这套方案，必须注意以下几个因浏览器机制带来的细节暗坑：

1. 垃圾回收与 Port 猝死（Garbage Collection）

MessagePort 受制于浏览器的垃圾回收机制（GC）。如果你的 P2PConnector 实例或者持有 port 的对象在某个函数执行完后没有被全局引用，浏览器可能会在不发出任何警告的情况下，自动关闭并回收这条通道。

• 避坑手段：如上文 SDK 所示，务必使用类似 this.activeConnections 这样的全局 Map/集合强引用住正在使用的 MessagePort。

2. 页面刷新导致端口残留（Port Leaks）

当一端页面刷新（F5）或关闭时，由于连接被强行切断，另一端的 MessagePort 并不总是能立刻触发 onmessageerror。如果此时继续往该端口发送消息，数据将石沉大海。

• 避坑手段：
  1. 心跳检测：在通道空闲时，每隔数秒通过 port 发送一个 ping/pong 包，超时未回则认为对方已死，主动调用 port.close()。
  2. 利用 beforeunload 事件：在页面即将销毁时，通过 BroadcastChannel 或向 SW 发送一个广播 DISCONNECT 信号，让配对端主动释放资源。

3. ServiceWorker 的生存期（SW Lifespan）

部分浏览器为了省电，会在没有网络请求和主线程任务时，将后台运行的 ServiceWorker “冻结/休眠”。

• 不必担心：由于我们的设计中，ServiceWorker 仅作为瞬时媒婆参与连接建立阶段。一旦 port 转移完毕，两端的 TCP/内存通道已经打通，此时即使 ServiceWorker 进程进入休眠，完全不会影响已经建立的 MessagePort 的后续数据传输。

方案对比：为什么这是最优解？

总结

在 SharedWorker 逐渐退居二线、浏览器安全策略愈发收紧的今天，“利用 ServiceWorker 转移 MessagePort” 的 P2P 模式，为高要求的 Web 多标签架构提供了一条兼顾兼容性与极致性能的黄金通道。

它不仅优雅地避开了 SharedWorker 的兼容大坑，还彻底终结了 BroadcastChannel 带来的广播风暴。如果你的 Web 应用正在面对高频跨页面数据通信的挑战，不妨尝试用这套架构进行一次性能重构。