前端 WebSocket 重连怎么避免旧连接复活：close 竞态、指数退避与状态收敛

页面上的实时通知偶尔会出现一个很难复现的现象：网络断开后明明已经建立了新 WebSocket，几百毫秒后状态又跳回“断开”，随后重复创建连接。问题往往不是服务器拒绝，而是旧连接的 close 回调晚到，覆盖了新连接留下的状态。

旧连接为什么会把新连接状态改回 CLOSED

浏览器的 WebSocket 对象各自维护 readyState，连接关闭时异步派发 close 事件。页面代码如果把当前状态写在共享变量里，就可能出现下面的时序：

1. t0：socket A 断网，开始关闭，但它的 close 事件还没派发。
2. t1：重连逻辑创建 socket B，并把共享状态写成“连接中”。
3. t2：socket B 已经 OPEN，socket A 的回调才到达，把共享状态写成“断开”。

这里别急着给 close 事件加延时。延时只能改变撞车概率，不能证明回调属于哪一个连接。真正要比较的是连接身份。

把“当前连接”从布尔值升级为连接代次

每创建一次 socket，就把 generation 加一，并在闭包中保存本次连接的代次。任何异步回调执行时，先比较它和当前代次；不相等就说明它属于旧连接，只能清理自己的资源，不能更新页面主状态。

let socket = null;
let generation = 0;
let retryCount = 0;
let manuallyClosed = false;

function connect() {
  const mine = ++generation;
  const ws = new WebSocket('wss://example.test/events');
  socket = ws;

  ws.addEventListener('open', () => {
    if (mine !== generation) return;
    retryCount = 0;
    renderStatus('OPEN');
  });

  ws.addEventListener('close', (event) => {
    if (mine !== generation) return;
    socket = null;
    renderStatus(`CLOSED ${event.code}`);
    if (!manuallyClosed) scheduleReconnect(mine);
  });
}

socket === ws 也可以作为身份判断，但代次更容易和重连定时器一起传递。尤其是旧 socket 的 close 回调触发后，变量 socket 可能已经指向 B，单靠共享状态很难解释这次回调是谁留下的。

指数退避要和代次校验放在同一条链路

断线后别立刻无间隔发起新连接。写个简单的延迟逻辑就能把接连失败的请求错开，同时给服务端和浏览器的网络栈留足恢复时间：

function scheduleReconnect(mine) {
  const attempt = retryCount++;
  const delay = Math.min(1000 * 2 ** attempt, 30000);

  window.setTimeout(() => {
    if (mine !== generation || manuallyClosed) return;
    connect();
  }, delay);
}

退避只解决“什么时候重试”的问题，代次校验负责判断“谁有资格发起重试”，两者搭配用效果才好：没做退避很容易引发重连风暴，没加代次判断的话旧定时器会在新连接已经建立之后重复创建socket。

手动关闭、异常断线和页面卸载必须分开

退出登录、切换工作区这类场景，业务一般要求连接彻底终止；普通网络掉线的场景才需要继续尝试重连。可以把主动关闭设为独立的显式状态，调用关闭逻辑的时候先把当前代次直接置为失效：

function disconnect() {
  manuallyClosed = true;
  generation += 1; // 让旧回调和旧定时器立即失去资格
  if (socket && socket.readyState 

页面卸载时不需要启动下一轮重连。可以在路由销毁或组件卸载阶段调用 disconnect()，避免计时器和事件监听器继续持有旧对象。

用可观测事件验证状态是否真正收敛

不要只在界面上打印“已连接”。调试时至少记录连接代次、事件类型、readyState、关闭码和重试次数，才能看出旧回调是否越权：

浏览器规范中的 CloseEvent 会提供 code、reason 和 wasClean。它们适合做诊断信息，但不要把某一个关闭码硬编码成“永远重连”或“永远不重连”；重连策略还要结合业务是否主动退出。

迁移旧实现时的回归检查

• 连续快速触发两次 connect()，确认第一次连接的 close 不会覆盖第二次的 OPEN。
• 等待退避计时器的过程中模拟网络恢复，确认旧定时器不会额外生成多余的socket实例。
• 调用 disconnect() 后等待超过最大延迟，确认没有新的连接创建。
• 让连接成功后再断开，确认 retryCount 清零，而不是沿用之前的长延迟。
• 记录两次重连之间的实际等待时长，确认上限为30000毫秒，不会出现指数溢出导致等待时间无限变长的问题。

如果用的组件框架自带卸载钩子，就把连接清理逻辑放在对应位置执行；如果连接由全局单例统一管理，就要把“谁有权限主动关闭连接”的规则写清楚，避免页面组件和全局服务各自跑一套独立的重连循环。

常见问题

WebSocket 的 close 事件能保证最后一个连接才触发吗？

不能。每个连接对象都有自己独立的生命周期，旧连接的事件回调触发时间完全可能晚于新连接完成初始化的时间。业务逻辑里要通过对象身份或者连接代次做判断，确认当前回调还有权修改全局连接状态。

只判断 readyState === WebSocket.OPEN 够不够吗？

不够。readyState 只能说明某个对象自身的状态，不能说明它是不是业务当前使用的对象；还要叠加代次或对象引用校验。

为什么重连一定要设置最大延迟？

不加上限的话，连续失败会让等待时间不断翻倍扩大，用户恢复网络后要等很久才能重新连上，反馈体验很差。设置合理上限之后，重连恢复的等待时间可以保持在可预期范围内，也能避免短间隔反复请求给服务端带来额外压力。

服务端主动关闭时要不要自动重连？

优先参考业务语义做判断。登录失效、权限撤销这类明确不可恢复的状态可以直接停止重连；临时服务维护或者普通网络抖动的场景一般可以继续尝试重连。WebSocket的关闭码只能作为判断线索，最终要不要重连的规则要由业务状态决定。

迁移清单

把共享布尔状态替换为“当前对象 + 连接代次”，给 open、close、error 和重连定时器统一加资格检查，再把手动关闭标记纳入同一条状态机。最后用快速双连、恢复网络、主动退出和成功后再次断线四组场景验证，页面上的连接状态才算真正收敛。