客户端WebSocket心跳需在onopen后用setInterval定时发送轻量数据（如"ping"或{"type":"ping"}），间隔≤45秒（推荐30秒），并配合超时检测与onclose清理，确保兼容中间设备且覆盖全连接生命周期。
客户端 WebSocket 心跳怎么发？用 setInterval + ws.send() 就够了，但必须控制间隔和内容格式
Workerman 本身不干涉客户端行为，所以心跳发送完全由前端控制。最常见、最稳妥的方式是连接建立后立即启动一个定时器，按固定间隔发轻量数据包。关键不是“能不能发”，而是“发什么”和“什么时候发”。
常见错误现象：WebSocket is already in CLOSING or CLOSED state、Failed to execute 'send' on 'WebSocket': Still in CONNECTING state、心跳发了但服务端没响应、客户端误判断连反复重连。
- 必须在
ws.onopen回调里启动定时器，不能在new WebSocket()后立刻发 —— 此时连接可能还没真正就绪 - 心跳内容建议用纯字符串或极简 JSON，例如
"ping"或{"type":"ping"}；避免带时间戳（如ts）除非服务端真要校验，否则徒增解析负担 - 间隔设为 ≤45 秒（推荐 30 秒），确保小于所有常见中间件超时（Nginx 默认 60s、运营商 NAT 普遍 60–90s）
- 不要用
setTimeout递归模拟定时器 —— 一旦某次发送失败或延迟，后续全乱套；必须用setInterval保证节奏稳定
const ws = new WebSocket('wss://api.example.com');
ws.onopen = () => {
// 立即开始心跳，30 秒一次
ws.heartbeat = setInterval(() => {
if (ws.readyState === WebSocket.OPEN) {
ws.send('ping');
}
}, 30000);
};
ws.onclose = () => {
clearInterval(ws.heartbeat);
};
为什么不能只发空字符串或二进制 \x00？
空字符串 '' 在部分浏览器或代理（尤其是旧版 Nginx）中可能被静默丢弃或截断；而裸二进制如 \x00 容易触发 WebSocket 协议层校验失败或被防火墙拦截。这不是 Workerman 的限制，而是跨网络链路的兼容性现实。
使用可读 ASCII 字符串（如 "ping"）或标准 JSON（无嵌套、无多余空格）能最大程度通过各类中间设备。实测中，"p" 这种单字符也有效，但可读性和调试成本太低，不推荐。
- 别用
ws.send(new ArrayBuffer(1))—— 二进制帧需显式设置binaryType，且服务端onMessage收到的是string还是Buffer取决于 Workerman 版本和 WebSocket 配置，极易出错 - 如果服务端约定用前缀识别心跳（如
\x01ping），客户端必须用Uint8Array构造并确保编码一致，否则onMessage收到的是乱码 - 移动端 WebView（尤其 Android 4.x–8.x）对非 UTF-8 字符串支持差，JSON 中避免 emoji 或中文字段名
前端怎么判断心跳是否失效？不能只看 onerror
onerror 是兜底事件，触发时连接往往已不可逆损坏；真正的心跳失效检测，得靠业务层超时机制：发完 ping 后启动一个独立计时器，等 pong，超时就主动 close 并重连。
很多项目只监听 onmessage 却不区分 ping/pong 和业务消息，导致 pong 响应被当普通数据处理，或根本没监听 —— 这会让客户端永远不知道服务端是否还活着。
- 必须在
ws.onmessage里做类型判断：if (event.data === 'pong' || (typeof event.data === 'string' && JSON.parse(event.data)?.type === 'pong')) - 每次发
ping前清掉上一个等待定时器：clearTimeout(ws.pingTimeout)，再ws.pingTimeout = setTimeout(..., 60000) - 超时阈值建议设为心跳间隔的 2 倍（如 30s 心跳 → 60s 超时），容忍一次丢包或服务端短暂卡顿
- 别在
onclose里直接重连 —— 需先判断event.code，1006（abnormal closure）才该重连，1000（normal）说明是服务端主动下线
移动端弱网下心跳发不出怎么办？
4G 模组、车载终端、IoT 设备在信号边缘区常出现「TCP 连接看似建立成功，但首条 WebSocket 消息发不出去」的情况。此时前端定时器照常运行，但 ws.send() 实际失败且不抛异常 —— 你看到的只是静默丢包。
真正的难点不在发送逻辑，而在如何感知这种“假连接”。Workerman 服务端收不到 ping，自然会在 90 秒后清理，但客户端毫无察觉，还在傻等 pong。
- 首次连接后，立即发一条带唯一 ID 的心跳（如
{"type":"ping","id":"cli_abc123"}），并在服务端onMessage中强制记录该 ID 到 Redis 或内存表；客户端启动一个 10 秒探测定时器，查这个 ID 是否被服务端登记 —— 没登记就说明首条消息丢了，立刻 close 重试 - Android WebView 下，
navigator.onLine不可靠，优先用fetch('/health')检查 HTTP 层连通性，再建 WS - 别依赖
ws.bufferedAmount判断发送状态 —— 它只反映浏览器内部缓冲区，不反映是否抵达服务端，且在弱网下长期 > 0
setInterval，而是让心跳逻辑覆盖所有连接生命周期：从 onopen 启动、onmessage 响应、onclose 清理，再到弱网下的探测补救 —— 漏掉任一环，长连接就在你不知道的时候悄悄断了。 
