如何利用“单例模式”配合闭包确保在单页应用中全局仅存在一个 WebSocket 长连接实例

如何利用“单例模式”配合闭包确保在单页应用中全局仅存在一个 WebSocket 长连接实例

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

为什么不能直接 new WebSocket() 多次调用

在单页应用（SPA）开发中，如果每个页面或组件都随意调用 new WebSocket(url)，会导致多个独立的物理连接同时建立。这不仅会造成服务端资源浪费，将同一个客户端识别为多个独立会话，还可能引发消息重复接收、状态管理混乱等问题。更关键的是，重连逻辑会分散在各个组件中，难以统一控制。在 uni-app、Taro 等跨端框架中，问题更为突出——new WebSocket() 这一原生 API 仅在 H5 环境有效，在小程序或 App 端并不可用。直接使用将导致代码无法跨平台运行，破坏项目的一致性。

闭包单例如何避免多次初始化

核心解决方案是利用立即执行函数表达式（IIFE）结合闭包，将连接实例变量封装在私有作用域内，确保全局唯一。外部只能通过暴露的 getInstance() 方法获取实例，首次调用时创建连接，后续调用均返回同一实例：

const WebSocketSingleton = (function () {
  let instance = null
  return {
    getInstance: function (url) {
      if (!instance) {
        // 这里必须用平台兼容的 API，比如 uni-app 用 uni.connectSocket
        instance = {
          url,
          socket: null,
          connect() {
            uni.connectSocket({ url })
            uni.onSocketOpen(() => { /* 存引用 */ })
            uni.onSocketMessage((e) => { /* 转发给监听者 */ })
          },
          send(data) { uni.sendSocketMessage({ data }) }
        }
      }
      return instance
    }
  }
})()

• 当再次调用 WebSocketSingleton.getInstance('wss://...') 时，由于闭包内 instance 已存在，会直接返回现有实例，避免重复创建连接。
• 这里需注意一个潜在风险：即使传入不同的 url 参数，闭包逻辑仍可能返回首次创建的实例。这虽保证了唯一性，但也意味着后续传入的新 URL 会被忽略。因此，务必确保所有调用处传入的 WebSocket 地址完全一致。
• 若项目需要连接多个不同的 WebSocket 服务端点（例如区分消息服务和通知服务），建议将 URL 配置集中管理，或扩展单例模式以支持多实例键值对存储，而非在 getInstance 中动态传入。

uni-app 下必须用 uni.connectSocket，不是可选项

在 uni-app 项目中，必须使用官方提供的 uni.connectSocket API 来建立跨端一致的 WebSocket 连接。该 API 在不同平台底层实现不同，使用时需遵循以下规范：

• 调用时机：应在页面的 onReady 生命周期之后调用。在 onLoad 阶段调用可能导致在 App 端连接失败。
• URL 协议：必须使用安全的 wss:// 协议。小程序平台会强制校验，仅 H5 环境在本地调试时可临时使用 ws://。
• 参数编码：查询参数需使用 encodeURIComponent 进行编码。例如 ?token=abc+def 若不编码，可能在传输过程中被截断或解析错误，导致连接异常断开。
• 发送时机：必须在 uni.onSocketOpen 连接成功事件触发后才能调用 uni.sendSocketMessage 发送消息，否则会抛出“websocket not connected”错误。

断开重连和状态清理最容易被忽略

实现单例模式只是第一步，连接的生命周期管理同样关键。在实际应用中，网络波动、应用切换至后台、小程序被系统回收等场景都会触发连接断开。若仅依赖单例而不处理重连与清理，instance.socket 可能仍持有无效引用，导致消息发送静默失败。

• 状态重置：在 uni.onSocketClose 或 uni.onSocketError 事件回调中，必须手动将 instance.socket 置为 null，并清理相关监听器，为重新连接做好准备。
• 智能重连：重连机制不建议使用固定时间间隔的 setTimeout。应采用指数退避策略，例如首次重连等待 1 秒，第二次 3 秒，第三次 9 秒……通常设置最大重试次数（如 5 次），避免无限重连消耗资源。
• 生命周期同步：在 App 或小程序的 onHide 生命周期中，应主动调用 uni.closeSocket() 并重置单例状态。当用户返回应用时，再按需重新建立连接，避免持有“僵尸连接”。

总而言之，闭包单例模式确保了 WebSocket 实例在全局范围内的唯一性，但连接的稳定性、错误恢复能力以及与应用生命周期的协同，仍需开发者通过完善的重连、清理和状态同步机制来保障。忽略这些细节，单例模式将只是一个易于维护却缺乏健壮性的架构外壳。