前端 WebSocket 退避重连 怎样处理

前端 WebSocket 断开后，重连不能写成“收到 close 就立刻 new WebSocket”。更稳妥的做法是：先用主动关闭标记判断是否应该继续，再用指数退避限制频率，并给等待时间加入少量随机抖动；连接成功后清零失败次数，鉴权失效、页面离开等不可恢复状态则直接停止。

官方文档入口：https://developer.mozilla.org/en-US/docs/Web/API/WebSocket

用状态和等待时间控制重连起点

浏览器的 WebSocket.readyState 有 CONNECTING、OPEN、CLOSING、CLOSED 四种状态。重连控制器只负责创建处于 CONNECTING 的新连接，不能在旧连接还没结束时重复创建。更重要的是，业务主动调用 close() 时要先把 shouldReconnect 设为 false，否则正常退出也会被当成断线。

最小实现：指数退避、上限和随机抖动

下面的控制器把重连策略集中在一个对象里。第 attempt 次失败的基础等待时间为 baseDelay × 2^attempt，但不超过 maxDelay；再加入一个 0 到 30% 的随机量，让同一时刻断开的客户端不要排成整齐的请求波峰。

class ReconnectingSocket {
  constructor(url, { baseDelay = 500, maxDelay = 30_000, maxAttempts = 8 } = {}) {
    this.url = url;
    this.baseDelay = baseDelay;
    this.maxDelay = maxDelay;
    this.maxAttempts = maxAttempts;
    this.attempt = 0;
    this.shouldReconnect = true;
    this.timer = null;
    this.socket = null;
  }

  connect() {
    // 每次只创建一个新连接，旧连接仍处于关闭过程时不重复连接。
    if (!this.shouldReconnect || this.socket?.readyState === WebSocket.OPEN) return;

    this.socket = new WebSocket(this.url);
    this.socket.onopen = () => {
      // 成功建立连接后，下一次故障从最短等待重新开始。
      this.attempt = 0;
    };
    this.socket.onmessage = (event) => this.onMessage?.(event.data);
    this.socket.onerror = () => {
      // error 只记录现象，重连统一交给 close，避免调度两次。
    };
    this.socket.onclose = (event) => this.handleClose(event);
  }

  handleClose(event) {
    // 主动关闭或鉴权失效后，不再安排新的连接。
    if (!this.shouldReconnect || event.code === 1008) return;
    if (this.attempt >= this.maxAttempts) return;

    const exponential = Math.min(this.maxDelay, this.baseDelay * 2 ** this.attempt);
    const jitter = exponential * (0.7 + Math.random() * 0.3);
    this.attempt += 1;
    this.timer = window.setTimeout(() => this.connect(), jitter);
  }

  close() {
    // 先改变策略状态，再取消定时器，防止 close 事件反向触发重连。
    this.shouldReconnect = false;
    if (this.timer !== null) window.clearTimeout(this.timer);
    this.socket?.close(1000, "client shutdown");
  }
}

这里让 error 只记录问题，把真正的重连入口统一放在 close。浏览器在连接建立失败时通常会先触发错误事件，再以关闭事件收口；两处都调度会让一次失败产生两个定时器。示例把 1008 视为策略或鉴权拒绝的信号，实际项目应根据服务端约定的关闭码调整，不能把所有关闭码都硬编码成永久停止。

把重试策略接到页面生命周期

重连计时器并不是越可靠越好。页面进入后台时，定时器可能被浏览器节流；网络恢复时，用户希望尽快恢复；而 token 过期时，继续重连只会反复得到拒绝。把这些事件接到控制器，策略会比单纯监听 close 更可控。

如果业务有发送队列，还要设置队列长度和消息过期时间。连接断开期间不要无限缓存；超出上限时优先丢弃可重建的状态同步消息，并保留用户明确触发的操作。连接恢复后先完成鉴权和状态同步，再开放普通业务发送，避免旧消息与新状态交错。

上线前的边界检查

第一，关闭连接时使用正常关闭码并取消定时器，确保组件卸载不会留下后台重连。第二，把连续失败次数、最近关闭码、等待毫秒数和最终停止原因写入日志，但不要记录 token 或完整消息体。第三，给重连设置最大次数或最大总时长；服务端持续拒绝时，应该显示“需要重新登录”或“稍后重试”，而不是让用户看到无穷无尽的旋转状态。

常见问题

为什么不直接每 1 秒重连一次？

固定间隔会让大量客户端同时重连，服务恢复瞬间容易形成波峰。指数退避和抖动能把请求分散到更长时间窗口。

收到 error 后要不要立即重连？

不建议。把 error 当作记录入口，把调度统一放在 close，否则同一次故障可能创建两个连接。

连接成功后为什么要把 attempt 清零？

连续失败次数描述的是当前故障段。中间已经成功连接，下一次独立故障应从短等待开始，否则一次历史故障会让后续恢复变得过慢。