固定间隔重连会引发重连风暴，导致后端雪崩；应采用带随机抖动（jitter）的指数退避策略，即第n次延迟为min(1000×2ⁿ,30000)×[0.5,1.0]，并配合重试计数、状态判断与定时器清理。
为什么直接用固定间隔重连会压垮后端
客户端在高并发场景下如果统一用 3s 或 5s 固定间隔重连，所有连接会在断线后几乎同时发起请求，形成“重连风暴”。尤其当网关或 WebSocket 服务刚恢复时，瞬间涌入的海量 CONNECT 请求可能触发限流、CPU 尖刺甚至雪崩。
指数退避不是“越等越久”就行，关键是要加入随机化（jitter），避免重连时间对齐。标准做法是：第 n 次重连等待时间为 min(base * 2^n, max_delay)，再乘以一个 [0.5, 1.0] 的随机因子。
-
base建议设为1000（1 秒），太小起不到错峰作用，太大影响用户体验 -
max_delay控制上限，推荐30000（30 秒），避免用户长时间卡在“重连中” - 必须加 jitter，否则集群里成千上万客户端仍会周期性撞车
JavaScript 中用 setTimeout 实现带 jitter 的退避
浏览器环境不能用 sleep，得靠 setTimeout 驱动状态机。重点在于每次重连失败后更新下次延迟，并清除上一次定时器，防止内存泄漏和重复触发。
let retryCount = 0;
const BASE_DELAY = 1000;
const MAX_DELAY = 30000;
<p>function getNextDelay() {
const exponential = Math.min(BASE_DELAY <em> Math.pow(2, retryCount), MAX_DELAY);
return exponential </em> (0.5 + Math.random() * 0.5); // jitter [0.5, 1.0]
}</p><p>function connectWithRetry() {
const ws = new WebSocket('wss://api.example.com/ws');</p><p>ws.onopen = () => {
retryCount = 0; // 成功则重置计数
};</p><p>ws.onerror = (err) => {
console.error('WS error:', err);
};</p><p>ws.onclose = () => {
if (ws.readyState !== WebSocket.OPEN) {
retryCount++;
const delay = getNextDelay();
console.log(<code>Reconnecting in ${Math.round(delay)}ms (attempt ${retryCount})</code>);
setTimeout(connectWithRetry, delay);
}
};
}</p>
- 不要在
onclose里无条件重试——得先判断ws.readyState，否则onclose可能被触发多次 -
retryCount必须是闭包外变量或存在组件实例上，否则每次调用都从 0 开始 - 实际项目中建议加最大重试次数限制（如
retryCount > 10后暂停并提示用户），避免无限循环
Node.js 后端用 ws 库做客户端重连时的坑
用 ws 包写上游服务（比如代理网关）时，WebSocket 实例的 on('close') 事件不会自动触发重连逻辑，必须手动监听并控制生命周期。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 务必监听
'error'事件并destroy()实例，否则 socket 可能处于半开状态，不触发'close' -
new WebSocket(url)失败时（如 DNS 失败、ECONNREFUSED）会抛出异常，需用try/catch捕获，不能只靠事件监听 - 使用
ws.terminate()而非ws.close()强制结束连接，确保底层 socket 真正释放 - 退避逻辑要绑定到具体连接实例上，不同下游服务应有独立的
retryCount，不能全局共享
如何验证退避是否真正生效
光看日志里“attempt 1/2/3”没用，得确认时间戳是否真的散开。最简单方式是在重连日志里打上毫秒级时间戳：
console.log(`${new Date().toISOString()} - Reconnecting in ${delay}ms`);
然后用 grep 抽出重连行，用脚本算相邻两次间隔的标准差。如果标准差远小于均值（比如 stddev / mean ），说明 jitter 没起作用，大概率是忘了乘随机因子或用了 <code>Math.random() 以外的伪随机源。
另一个信号是观察后端 access log 中 GET /ws 请求的时间分布——正常退避下，请求应呈近似均匀的泊松分布，而非每隔几秒就出现一个尖峰。
最容易被忽略的是：前端多个 tab 共享同一域名时，localStorage 或全局变量导致 retryCount 被意外共享，结果所有 tab 同步退避。这种情况必须用 sessionStorage 或 WeakMap 隔离实例状态。
