前端 WebSocket 断线重连为什么会打爆接口：指数退避、抖动与页面恢复

行情页刚发布了一个小改动，几分钟后接口监控却跳出一条异常尖峰：WebSocket 连接数先掉了一大截，随后连接建立请求在同一分钟内翻了好几倍。浏览器端的代码都在“自动努力恢复”，但每个打开的标签页都立刻发起重连，结果把原本只是短暂的网络抖动，直接放大成了打崩服务端的重连风暴。

先从连接事件还原重连风暴的现场

排查时先给每个连接实例分配一个短标识ID，把 open、close、error 和下一次计划重连的时间点打到同一条日志里。只看“连接断开”四个字的日志，根本没法判断是服务端主动关闭、网络切换还是代码写重复了、同时调度了多个定时器。

const state = {
  socket: null,
  timer: null,
  attempt: 0,
  stopped: false
};

function logConnection(event, extra = {}) {
  console.info('[realtime]', {
    event,
    attempt: state.attempt,
    visible: document.visibilityState,
    ...extra
  });
}

重点核对两个时间维度：连接断开到下一次连接开始发起的间隔，以及同一个页面里是否同时存在多个未执行的重连计时器。如果第二项异常，先把状态管理的bug修好，再去讨论退避参数怎么调。

指数退避解决什么问题，随机抖动又解决什么

固定1秒重连看起来代码好写逻辑简单，但只要服务端刚从故障里恢复，所有浏览器都会在同一个时间点同时发起握手。指数退避会把单个客户端的尝试间隔逐步拉长，分散后续重试的集中程度；随机抖动则进一步把一批客户端的请求时间点彻底打散，避免集中撞库。

function nextDelay(attempt) {
  const base = 1000;
  const cap = 30000;
  const backoff = Math.min(cap, base * 2 ** attempt);
  const jitter = Math.floor(Math.random() * 800);
  return backoff + jitter;
}

function scheduleReconnect() {
  if (state.stopped || state.timer) return;
  const delay = nextDelay(state.attempt);
  logConnection('reconnect-scheduled', { delay });
  state.timer = window.setTimeout(() => {
    state.timer = null;
    state.attempt += 1;
    openSocket();
  }, delay);
}

退避上限不是设置得越大越好。实时数据看板可以接受几十秒后再恢复同步，交易确认页则需要直接把“暂时离线”的状态显式告知用户，不要用无限重连来掩盖业务异常状态。超过退避上限后可以降低客户端日志的上报频率，避免客户端和服务端一起被大量重试日志拖慢。

让 open、close 和 stop 共用一套生命周期管理

连接函数要先清理掉旧的连接对象，再重新绑定事件；连接打开成功后立刻把重连尝试次数归零。关闭事件只负责判断当前场景下是否需要发起恢复，真正的计时器统一由 scheduleReconnect 来创建调度。

function openSocket() {
  if (state.stopped || document.visibilityState !== 'visible') return;
  const socket = new WebSocket('wss://example.com/realtime');
  state.socket = socket;

  socket.addEventListener('open', () => {
    state.attempt = 0;
    logConnection('open');
  });
  socket.addEventListener('close', (event) => {
    logConnection('close', { code: event.code });
    scheduleReconnect();
  });
  socket.addEventListener('error', () => logConnection('error'));
}

function stopSocket() {
  state.stopped = true;
  if (state.timer) window.clearTimeout(state.timer);
  state.timer = null;
  state.socket?.close(1000, 'page-stop');
  state.socket = null;
}

这里别把 error 和 close 都当成一次重连的入口。很多浏览器的WebSocket事件机制会先抛出error事件再触发close事件，两个入口各自调度计时器，直接就会跑出多条并发连接。

页面隐藏时暂停，重新可见时再主动恢复

标签页切到后台之后，大部分场景下实时数据都没有继续展示的价值；移动端环境下浏览器还可能主动暂停后台页面的定时器。可以监听 visibilitychange 事件：页面隐藏时关闭现有连接并停止所有待执行的重连逻辑，页面恢复可见时再单独开启一个新的连接。

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    stopSocket();
    return;
  }
  state.stopped = false;
  state.attempt = 0;
  openSocket();
});

如果业务场景明确允许页面后台接收消息，就不要直接硬套这段暂停逻辑，改成连接降频或者交给专门的后台消息通道处理就好。核心是先由产品需求决定“页面隐藏时是否还需要维持实时连接”，再反过来决定对应的技术策略。

上线前用四个信号判断策略是否真的稳定

一次成功的连接恢复，不能证明整套重连策略没有漏洞。建议在测试环境主动断网、切换Wi-Fi与蜂窝移动网络、让服务端返回1011状态码，再观察以下几个指标：

回滚故障时优先恢复上一版成熟的连接状态机，不要简单粗暴把退避时间直接改回0。如果服务端已经处在握手压力过载的状态下，客户端立刻全部发起重连只会继续放大故障；先把客户端的整体重试速率压下来，才能给服务端恢复留出足够空间。

常见问题：重连策略里的三个边界

为什么指数退避还需要加随机数？

指数退避只是拉长了每个客户端的重试间隔，没法保证同一批客户端不会在完全相同的时刻发起重试。随机抖动能把这批请求均匀分散到预设的时间窗口内。

WebSocket close 之后要不要马上 new 一个新连接？

除非这是用户主动点击重试、且服务端明确已经恢复可用，否则不建议立即发起重连。先判断当前页面的运行状态，再走统一的退避调度流程。

页面恢复可见时为什么不能直接复用旧的 socket 对象？

页面隐藏期间网络环境和浏览器调度逻辑都可能发生变化，旧的socket大概率已经处于半关闭的无效状态。主动清理旧对象、重置重连尝试次数，再创建一个受状态管理约束的新连接，后续出问题也更容易排查验证。

收尾：把“盲目努力重连”变成可控的恢复流程

稳定可用的WebSocket重连，不是把 setTimeout 简单套在 close 事件里，而是让连接状态、退避时间、页面可见性和停止动作共享同一套边界规则。上线后如果能同时清晰回答“当前有几个活跃连接、下一次何时重试、这次重试的触发原因是什么、最终恢复用了多久”，这套方案才算真正达到可运维的标准。