HTML5WebSocket重连机制_HTML5断线自动重连与指数退避实现教程【指南】

onclose不触发的根本原因是监听器绑定过早或被覆盖，应确保在new websocket()后、readystate为0时绑定，优先使用addEventlistener避免覆盖；重连需指数退避并限制次数。

WebSocket 断开后 onclose 不触发？检查事件监听时机

很多重连逻辑失效，根本原因不是重连写得不对，而是 WebSocket 实例还没创建完，就提前绑定了 onclose —— 或者更糟：监听器被反复覆盖。

• onclose 必须在 new WebSocket(...) 之后、且在连接建立前（即 readyState === 0 时）绑定，否则可能漏掉初始连接失败
• 不要在每次重连时重新赋值 ws.onclose = function() {...}，用 ws.addEventListener('close', handler) 更稳妥，避免覆盖已有监听器
• 如果服务端直接拒绝握手（如 401/403），onclose 仍会触发，但 event.code 是 4000+，event.reason 可能为空；此时靠 onerror 捕获并不可靠，优先以 onclose 为准

指数退避重连怎么写才不炸服务器？控制 reconnectDelay 上限和重试次数

无脑 setTimeout(() => connect(), 1000) 在网络抖动时会瞬间打出几十个连接请求，服务端扛不住，客户端也容易被限流。

• 基础退避序列建议从 1000ms 开始，每次 ×1.6（比 ×2 更平滑），上限设为 30000ms（30 秒），避免长时卡死
• 必须设置最大重试次数（比如 5 或 10 次），否则网络彻底断开时会无限循环，消耗内存和 CPU
• 每次重连前清空上一次的 setTimeout ID，防止旧定时器在新连接成功后误触发
• 示例关键片段：

  let retryCount = 0;<br>const maxRetries = 5;<br>function connect() {<br>  ws = new WebSocket(url);<br>  ws.onclose = () => {<br>    if (retryCount < maxRetries) {<br>      const delay = math.min(1000 * Math.pow(1.6, retryCount), 30000);<br>      setTimeout(connect, delay);<br>      retryCount++;<br>    }<br>  };<br>}

重连时如何避免重复订阅或消息堆积？用 readyState 和唯一标识判断连接状态

重连后立刻发订阅消息，但新连接还没 ready，或者旧连接的回调还在执行，结果消息发丢了、重复了、或触发了两次相同业务逻辑。

• 发消息前务必检查 ws.readyState === WebSocket.OPEN，别只靠“我刚 new 完它就应该 ok”这种直觉
• 给每个连接实例打标记（如 ws._id = date.now() + '-' + Math.random().toString(36).substr(2, 9)），在 onmessage 中过滤掉非当前连接的消息（尤其当重连期间旧连接还在收包）
• 重连成功后，不要自动重发未确认消息 —— 除非协议层支持消息 ID 和 ACK，否则盲目重发可能破坏业务顺序
• 如果用了心跳（ping/pong），确保心跳检测逻辑不依赖于 onmessage，而用 onopen 后单独启动 setInterval，否则重连后心跳会断

浏览器标签页休眠导致 WebSocket 静默断开？监听 visibilitychange 主动干预

chrome/firefox 在标签页后台超过 30–60 秒后，会暂停定时器、冻结 WebSocket 连接，但 onclose 不一定立即触发，等切回页面才发现已断线。

立即学习“前端免费学习笔记（深入）”；

• 监听 document.addEventListener('visibilitychange', ...)，在 document.hidden === true 时主动 ws.close()，并清除重连定时器
• 切回前台（document.hidden === false）时，不立即重连，先等 500ms 再调用 connect()，避开系统恢复期的不稳定
• 注意：safari 对 visibilitychange 触发较慢，可叠加 pagehide/pageshow 做兼容
• 这个行为和 http Keep-Alive 无关，是浏览器对后台标签的主动节电策略，无法通过服务端配置绕过

重连逻辑真正难的不是写几行 setTimeout，而是得同时盯住连接状态、页面生命周期、服务端响应节奏这三根线——稍一松手，就会出现“看着在连，其实早断了”或者“连上了，但业务没跟上”的情况。