核心原因是缺乏主动心跳探测和重连节奏失控；需用双重定时器心跳（发包+超时确认）和指数退避+随机抖动重连，避免静默断开与重连风暴。
WebSocket连接在弱网环境下不稳定，核心原因不是协议本身，而是缺乏对“假死连接”的主动探测和重连节奏失控。单纯调大超时参数或加个 setInterval 心跳，反而会加剧断连感知延迟或引发重连风暴。
为什么 onclose 事件经常不触发？
弱网下 TCP 连接可能已中断，但 WebSocket 对象仍处于 OPEN 状态——这是典型的“静默断开”。浏览器不会主动通知，onclose 和 onerror 都不会被调用。
- 中间设备（如运营商 NAT、企业防火墙）在空闲 30–60 秒后单向切断连接，不发 FIN 包
- 客户端休眠唤醒后，底层 socket 已失效，但 JS 层无感知
- 服务端因 OOM 或进程崩溃退出，未发送 Close 帧
必须放弃依赖 onclose 的被动式处理，改为主动心跳探测。
客户端心跳检测怎么写才可靠？
不能只发 ping，必须配套超时判定和响应确认。关键在于：发送心跳包后启动一个独立定时器，若在规定时间内没收到 pong 或自定义响应，就主动关闭并重连。
- 使用
WebSocket原生ping/pong帧（推荐）：服务端需正确响应，且客户端要监听onpong事件；部分旧版 Safari 不支持暴露onpong，需降级为应用层心跳 - 应用层心跳更可控：发送
{"type":"heartbeat"}，服务端原样返回{"type":"ack"}，客户端用setTimeout控制等待窗口（建议 5–8 秒） - 心跳间隔设为 25–30 秒，略小于服务端
idle_timeout（如 EMQX 的heartbeat=30s），避免被中间设备误杀
示例片段：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
let heartbeatTimer;<br>let pongTimeoutTimer;<br><br>function startHeartbeat() {<br> heartbeatTimer = setInterval(() => {<br> if (socket.readyState === WebSocket.OPEN) {<br> socket.send(JSON.stringify({ type: 'heartbeat' }));<br> // 启动响应等待定时器<br> pongTimeoutTimer = setTimeout(() => {<br> console.warn('heartbeat timeout');<br> socket.close(4900, 'heartbeat timeout');<br> }, 6000);<br> }<br> }, 25000);<br>}<br><br>socket.addEventListener('message', (e) => {<br> const data = JSON.parse(e.data);<br> if (data.type === 'ack') {<br> clearTimeout(pongTimeoutTimer); // 收到响应，清除超时<br> }<br>});重连逻辑为什么不能线性递增？
线性重连（如每次 +1s）在弱网下极易造成“重连风暴”：1000 个客户端同时断开，第 2 秒全部重试，服务器瞬间涌入 1000 次握手请求，CPU 和连接数直接打满。
- 必须用指数退避：
delay = baseDelay * Math.pow(2, retryCount) - 必须加随机抖动（jitter）：乘以
0.5–1.5之间的随机因子，打散重连时间点 - 设置最大重试次数（如 5 次）和上限延迟（如 30 秒），避免无限等待
- 重连前检查网络状态：
navigator.onLine为false时暂停重连，等恢复后再触发
常见错误是把 retryCount 放在函数作用域内，导致每次调用都重置为 0——它必须是闭包外的持久变量或类成员。
服务端配置哪些参数最影响弱网表现？
客户端再努力，也绕不开服务端的超时策略。EMQX、Swoole、Nginx 代理层的几个参数一旦设错，客户端所有优化都白搭。
- EMQX：
listener.websocket.heartbeat=30s（发送 ping 间隔）、listener.websocket.idle_timeout=60s（最大空闲时间）必须成对调整，且idle_timeout > heartbeat - Nginx 代理：
proxy_read_timeout和proxy_send_timeout必须设为远大于心跳间隔（如86400），否则它会在 60 秒后主动断开连接 - Swoole：
heartbeat_check_interval和heartbeat_idle_time要与前端心跳节奏对齐，否则服务端先关连接，前端还傻等 pong - 所有服务端必须开启 TCP keep-alive，并确保系统级
net.ipv4.tcp_keepalive_time不低于 600 秒
最容易被忽略的是 Nginx 层——很多团队只优化了后端 WebSocket 服务，却忘了代理本身也在“掐脖子”。
