浏览器原生WebSocket不支持手动发送或监听opcode 0x9/0xA控制帧，ws.send('ping')仅为文本消息；前端须用应用层心跳（纯字符串'ping'/'pong'）、维护lastPongTime时间戳，并结合readyState与onerror事件协同判定连接活性。

浏览器里发不出真正的 PING 帧（opcode 0x9），ws.send('ping') 只是普通文本消息，不是协议级心跳——它不会触发自动 PONG 响应，也过不了中间设备的静默超时检测。

为什么前端无法手动发送或监听底层 ping/pong 帧

这是浏览器 Web API 的硬性限制：原生 WebSocket 实例不暴露帧控制能力。你调用 ws.ping() 会报错，监听 onping 事件也无效。所有基于 WebSocket 构造函数创建的连接，都只能收发应用层消息（text / binary 帧），无法构造、发送或捕获 opcode 0x9 / 0xA 控制帧。

真正能发 PING 帧的场景只存在于：

• Node.js 环境下使用 ws 或 uWebSockets.js 库（服务端或 Electron 客户端）
• 使用 WebSocketStream + underlyingSource 自定义流（Chrome 120+ 实验性支持，仍不开放 opcode 控制）
• 绕过 WebSocket 协议，直接用 WebTransport（非本文范围）

如何在前端模拟有效的心跳行为

必须退到应用层实现，且需服务端配合。核心是三件事：发纯字符串、收纯字符串、时间戳兜底。

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

立即学习“前端免费学习笔记（深入）”；

• 客户端定时 ws.send('ping') —— 必须是字面量 'ping'，不能是 {type: 'ping'} 或带空格/换行
• 服务端收到后立即 ws.send('pong')（不要 JSON 化，不要加字段）
• 客户端 onmessage 中优先做字面量判断：if (event.data === 'pong') { lastPongTime = Date.now(); return; }，之后再走 JSON.parse
• 维护 lastPongTime，并在每次发 ping 前检查：if (Date.now() - lastPongTime > 90000) { ws.close(); }

常见误判和漏处理的坑

很多项目把心跳混进业务消息通道，导致假死识别失败。典型问题包括：

• 服务端返回的 'pong' 被某条业务响应 JSON 里的 "type": "pong" 冲突，JSON.parse 后才判断，结果漏更新 lastPongTime
• 网络抖动导致 'pong' 晚于下一轮 'ping' 到达，客户端重复触发重连
• 没检查 ws.readyState === 1 就发心跳，连接实际已断开但状态未更新（尤其在页面切后台后）
• 中间件（如 Nginx、CDN）对 'ping' 字符串做了日志审计或限流，被当成异常流量拦截

真正可靠的连接活性判定，永远依赖 lastPongTime + readyState + onerror 三者组合；单靠任何一项都会漏掉“连接开着但发不出消息”的静默假死。