WebSocket 连接为什么总是 onclose？不是网络问题，是服务端没收到心跳
浏览器里 WebSocket 看似连上了，几秒到几十秒后突然触发 onclose，控制台没报错、抓包也看不到 RST，大概率是服务端主动踢掉了“静默连接”。HTTP/1.1 没有长连接保活语义，WebSocket 本身也不强制心跳——不发心跳，就等于断线。
常见错误现象：readyState === 1 后毫无征兆变成 0；服务端日志显示 “connection idle timeout” 或直接 close code 1001；用 wscat 手动连却稳定——说明问题出在前端没按服务端约定发心跳。
- 必须确认服务端要求的心跳格式：是
ping帧（二进制）、文本"ping"、还是自定义 JSON 字段（如{"type":"heartbeat"}） - 服务端超时阈值通常为 30–60 秒，前端心跳间隔建议设为该值的 2/3（如 40 秒发一次），避免边界抖动
- 不要依赖
ws.send()成功回调来判断心跳送达——它只表示数据进了浏览器发送队列，不代表抵达服务端
用 setInterval 发心跳？别碰，改用 setTimeout 链式调用
setInterval 在页面失焦、系统休眠或 JS 主线程阻塞时会严重漂移，导致心跳堆积或漏发。更糟的是：如果某次 ws.send() 失败（比如 readyState !== 1），setInterval 仍会继续触发，可能引发未捕获异常或重复重连。
正确做法是用 setTimeout 实现“发完再定下一次”，把心跳逻辑和连接状态绑定：
立即学习“前端免费学习笔记（深入）”；
function startHeartbeat() {
if (ws.readyState !== WebSocket.OPEN) return;
ws.send(JSON.stringify({ type: "heartbeat" }));
// 下次心跳只在本次成功后启动
heartbeatTimer = setTimeout(startHeartbeat, 40000);
}
// 连接打开后立即启动
ws.onopen = () => {
startHeartbeat();
};
// 连接关闭/异常时清除定时器
ws.onclose = ws.onerror = () => {
clearTimeout(heartbeatTimer);
};
- 每次发心跳前必须校验
ws.readyState === WebSocket.OPEN，否则send()抛错且不触发onerror - 不要在
onmessage里重置心跳计时器——服务端心跳响应是单向通知，不是双向 ACK - 移动端 WebView 中，
setTimeout在后台标签页可能被节流至最低 1s，需配合document.hidden暂停心跳
onmessage 收到 "pong" 就算心跳成功？服务端根本没发这个
很多人误以为 WebSocket 协议像 HTTP 一样需要客户端发 ping、服务端回 pong。实际上：标准 WebSocket 的 ping/pong 帧由浏览器底层自动处理，JS 层完全不可见。你看到的 "pong" 文本，几乎全是服务端按业务协议伪造的响应。
这意味着：如果服务端文档写的是 “收到 {"type":"ping"} 后返回 {"type":"pong"}”，那它和协议层的 ping/pong 完全无关，只是个业务约定。
- 不要监听
onmessage判断心跳是否成功——服务端可能根本不回任何消息，只默默续租连接 - 真正可靠的“心跳存活”信号只有两个：
ws.readyState === 1且最近一次send()没抛错 - 若服务端要求回执，应在
onmessage中解析业务字段（如data.type === "heartbeat_ack"），而非硬匹配字符串
心跳包内容为空或太小，Nginx/ALB 直接吞掉
某些反向代理（尤其是 Nginx 默认配置、AWS ALB 的 WebSocket 模式）会对“空消息”或“极短文本帧”做静默丢弃，认为是探测包或无效流量。结果就是：前端按时发了心跳，服务端收不到，连接被代理层切断。
解决方法很简单：让心跳载荷具备明确业务特征且长度可控。
- 避免发送空字符串
ws.send("")或单字符ws.send("1") - 推荐格式：
ws.send(JSON.stringify({ type: "heartbeat", ts: Date.now() }))（约 40 字符） - 如果服务端允许，优先用二进制帧：
ws.send(new Uint8Array([0x01]))—— 多数代理对二进制帧更宽容 - 检查 Nginx 配置中是否有
proxy_read_timeout小于心跳间隔，它会强制关闭空闲连接
心跳机制真正的复杂点不在代码，而在两端对“活跃”的定义是否一致：前端以为发了就算，服务端却要求带时间戳校验、或限定每分钟最多 5 次心跳。不看服务端文档，光调前端定时器，永远在修幻觉。
