必须用带上限、重置和防重复的指数退避重连：每次失败延迟翻倍，设最大延迟（如30s）和最大尝试次数（如10次），onopen重置计数，onclose清理定时器并加随机抖动（0–1000ms），组件卸载时需destroy清除ws和定时器。
直接结论：用 setTimeout 控制重连延迟，每次失败后把延迟翻倍，但必须设上限、重置计数、防重复触发——否则会雪崩。
为什么不能简单 setTimeout(connect, 1000) 循环重连
基础循环重连在断网恢复瞬间会触发“惊群效应”：成百上千客户端同时发连接请求，服务端瞬间被打满。指数退避的核心不是“慢”，而是“错峰”。它让每个客户端的重连时间点自然散开，降低并发压力。
- 没加限制时，
onclose可能被连续触发多次（比如网络抖动），导致多个setTimeout并行执行，产生多个WebSocket实例竞争连接 - 不重置
reconnectAttempts，成功连接后仍按高延迟等待下一次“重连”，浪费资源 - 不设
maxReconnectInterval，第10次重连会等 512 秒，用户早关页面了
JavaScript 客户端实现的关键三步
以下逻辑适用于原生 WebSocket，无需框架，兼容所有现代浏览器。
- 声明三个状态变量：
reconnectAttempts（当前尝试次数）、baseDelay（如1000）、maxDelay（如30000） - 在
ws.onclose里先清理旧定时器（如果有），再计算新延迟：const delay = Math.min(baseDelay * Math.pow(2, reconnectAttempts), maxDelay) - 只在
ws.onopen中重置reconnectAttempts = 0；ws.onerror里调用ws.close()触发onclose，不单独处理重连
示例片段：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
function connect() {
const ws = new WebSocket('wss://api.example.com');
<p>ws.onopen = () => {
console.log('connected');
reconnectAttempts = 0; // ✅ 成功才清零
};</p><p>ws.onclose = () => {
if (reconnectAttempts >= 10) return; // ✅ 达上限即停
const delay = Math.min(1000 * Math.pow(2, reconnectAttempts), 30000);
reconnectAttempts++;
setTimeout(connect, delay); // ✅ 递归调用，非并行
};</p><p>ws.onerror = () => ws.close(); // ✅ 统一走 onclose 流程
}必须加随机抖动（jitter）的两个原因
纯指数退避在大规模部署中仍有风险：如果所有客户端启动时间一致（比如 App 全局更新后冷启动），它们的重连节奏依然高度同步。加入随机偏移是工业级实践。
- 抖动范围建议为
0–1000ms，即delay += Math.random() * 1000 | 0 - 不要用
Math.random()生成大范围抖动（如 ±5s），会导致部分用户等待过久，体验断层 - uWebSockets 和 OkHttp 等成熟库默认带抖动，自己写 JS 时容易漏掉这点
容易被忽略的销毁与竞态问题
单页应用（SPA）或 React/Vue 组件卸载时，若未手动关闭 WebSocket，onclose 仍可能被触发，导致重连逻辑在已销毁上下文中执行——报错、内存泄漏、甚至发起无效请求。
- 暴露一个
destroy()方法，内部调用ws?.close()并清除待执行的setTimeoutID - 避免在
onclose里直接操作 DOM 或调用this.setState，先检查组件是否还存活 - 多个 WebSocket 实例共存时（如多标签页），用
localStorage或BroadcastChannel协调，确保同一时刻最多一个实例在重连
真正难的不是算出 2^k，而是让重连逻辑在各种边界条件下安静、可控、可终止。
