弱网心跳需自适应探测而非固定定时：用双重定时器（发送+超时确认）、间隔设25–30秒避开中间设备断连、结合网络质量反馈动态调整、区分协议层与应用层带确认心跳。

弱网环境下心跳检测频繁断开，本质不是心跳本身失效，而是固定节奏的心跳机制与网络抖动、设备休眠、中间网关策略不匹配。关键要放弃“一刀切”的定时发送，转向感知式、自适应、带确认的主动探测。

用双重定时器替代单一定时器

只调用 setInterval 发心跳包是最大误区——它不判断响应，也不管连接是否真通。必须配对使用：

• 发送心跳后立即启动一个独立 setTimeout（建议 5–8 秒），等待服务端 pong 或应用层 ack
• 超时未收到响应，立刻标记为“疑似断连”，主动 ws.close() 并触发重连
• 收到响应则清除该定时器，继续下一轮心跳

心跳间隔必须小于中间设备空闲阈值

运营商 NAT、企业防火墙、云负载均衡器普遍在 30–60 秒清理无流量连接。若心跳设为 60 秒，实际可能刚发完就被切断：

• 推荐客户端心跳间隔设为 25–30 秒（如 28 秒）
• 服务端 idle_timeout 需设为 ≥35 秒（如 EMQX 的 heartbeat=30s 实际对应服务端 35 秒容忍）
• 避免两端都设 60 秒——看似安全，实则大概率被中间设备静默掐断

引入网络质量反馈闭环

地铁、电梯、农田等场景信号波动剧烈，固定心跳反而加重负担或失效：

• 监听 navigator.onLine 和 fetch() 探测 DNS/HTTP 可达性作为辅助指标
• 连续 2 次心跳超时 → 心跳间隔缩短至 15 秒（激进保活）
• 连续 3 次成功 → 恢复为 28 秒；若仍不稳定，进一步启用随机抖动（±3 秒）防重连风暴
• 服务端同步返回网络质量建议（如 “当前链路 RTT 偏高，建议心跳延长至 40 秒”）

区分协议层与应用层心跳

原生 ping/pong 帧最轻量，但兼容性有坑（旧版 Safari 不暴露 onpong）：

• 优先尝试 WebSocket 原生 ping：发送 ws.send(new Uint8Array([0x89]))，监听 ws.onmessage 中 type=0xA 的帧
• 降级方案用应用层心跳：发送 {"type":"hb","ts":1726412645}，服务端必须原样回 {"type":"ack","ts":1726412645}，客户端比对时间戳防乱序
• 禁用仅发不收的“假心跳”——没有响应确认，等于没做