WebSocket连接后不发心跳，服务端默认60秒无数据即断连；因原生API不支持自动ping，须前端用setInterval每30–45秒主动send("ping")，并在onclose/onerror中clearInterval，配合失败计数与onmessage清零机制实现可靠保活。
WebSocket连接后不发心跳，服务端主动断连怎么办
多数 WebSocket 服务端（如 Nginx 代理、Spring Boot 的 WebSocketHandler、或云厂商网关）默认 60 秒无数据就关闭空闲连接。前端不主动发 Ping，连接大概率在 1–2 分钟内被静默断开。
浏览器原生 WebSocket 对象**不支持自动发送 Ping 帧**——这是关键前提。所谓“心跳”，必须由前端用业务消息模拟（比如发 {"type":"ping"}），或靠定时器触发 send()。
- 别依赖
ws.ping()：该方法不存在，WebSocketAPI 没有暴露底层 Ping 控制权 - 别等
onmessage回应再发：服务端可能只收不回，心跳只需单向保活 - 首次心跳应在
onopen后立即启动，避免刚连上就因延迟触发而掉线
用 setInterval 发心跳的正确姿势
最直接的方式是连接就绪后启动定时器，但要注意清理逻辑和异常兜底。
核心原则：定时器 ID 必须绑定到实例上（比如挂到 ws.heartbeatId），且在 onclose 和 onerror 中清除，否则页面未卸载时定时器持续运行，可能对已断开的 ws 调用 send() 报错 InvalidStateError: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state。
立即学习“前端免费学习笔记（深入）”；
- 推荐间隔设为 30–45 秒，比服务端超时阈值小 10–15 秒，留出网络抖动余量
- 心跳内容建议用轻量字符串，如
"ping"或{"t":"h"}，避免 JSON 序列化开销 - 不要在定时器里检查
ws.readyState === WebSocket.OPEN后再发——这个判断本身就有竞态，应优先try/catch包裹send()
const ws = new WebSocket('wss://api.example.com/ws');
ws.onopen = () => {
ws.heartbeatId = setInterval(() => {
try {
ws.send('ping'); // 纯字符串最快
} catch (e) {
// send 失败说明连接已异常，主动 close 触发重连逻辑
ws.close();
}
}, 35000);
};
<p>ws.onclose = () => {
if (ws.heartbeatId) clearInterval(ws.heartbeatId);
};</p><p>ws.onerror = () => {
if (ws.heartbeatId) clearInterval(ws.heartbeatId);
};心跳失败后要不要重连？怎么判断是真断连还是临时抖动
单纯 send() 抛异常不能直接判定连接死亡——可能是瞬间阻塞、浏览器切后台冻结定时器、或服务端短暂不可达。盲目重连反而加重服务端压力。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
更稳妥的做法是：连续 2–3 次心跳 send() 失败（且间隔内无 onmessage 到达），再触发重连。可借助计数器 + 时间窗口控制：
- 每次
send()成功，重置失败计数ws.pingFailCount = 0 - 每次
catch到错误，计数加一；若pingFailCount >= 3，执行ws.close()并启动重连流程 - 同时监听
onmessage，只要收到任意消息，立刻清零计数——说明链路实际畅通
注意：Chrome 在页面后台时，setInterval 可能被节流到最低 1 分钟一次，此时靠心跳保活会失效。如需强保活，得结合 Page Visibility API 检测可见性，后台时改用 setTimeout 递归+更宽松的间隔。
用 AbortController 管理心跳定时器是否更现代
目前不推荐。虽然 AbortController 能统一取消异步操作，但它**无法取消 setInterval** ——clearInterval 仍需手动调用。强行包装成 Promise 并用 abort() 触发清理，反而增加心智负担和兼容性风险（IE 完全不支持）。
真正值得升级的是心跳协议设计本身：如果服务端支持标准 WebSocket Ping 帧（RFC 6455），前端无需发业务心跳，只要确保 TCP 层不被中间设备 kill 即可——但这取决于服务端实现，前端无法控制。
所以现阶段，老老实实用 setInterval + 清理逻辑 + 失败计数，是最可控、兼容性最好、也最容易 debug 的方案。
容易被忽略的一点：移动端 WebView（尤其旧版 Android）对定时器精度极不敏感，30 秒定时器可能偏差 5–10 秒，心跳间隔宁可设宽松些，别卡死 30000 这个数字。
