客户端主动发 ping 是唯一可靠的心跳机制，服务端只需在 onmessage 中检测空字符串并调用 $connection->pong() 响应；因 workerman timer 全局且连接对象不可靠遍历，服务端无法安全定时向每个连接发 ping。
Workerman 服务端无法可靠地向每个连接发 Ping
Workerman 的 timer 是全局的，不是按连接绑定的。你在 onWorkerStart 里用 Timer::add() 启一个定时器，它只能执行一次回调，而回调里拿不到「当前活跃的 WebSocket 连接对象」——因为连接对象生命周期短、跨进程不可达，且 Workerman 没提供安全遍历所有连接的 API（Worker::$connections 在 timer 回调中可能为空或失效）。
强行遍历会导致：连接已关闭但对象未及时销毁，$connection->send() 报错；或并发修改连接状态引发内存异常。这不是设计缺陷，而是事件驱动模型下对资源安全性的取舍。
客户端发 Ping 是唯一可控、可验证的心跳发起方
只有客户端能确保：Ping 帧发出 → 等待 Pong 响应 → 超时即断连 → 触发重连。这个链路全程在单一线程/上下文中，不依赖服务端状态同步。
- 浏览器 WebSocket API 天然支持
onclose和onerror，能捕获 1001 / 1006 等静默断开码 - 移动端 WebView 或原生 SDK 也能精确控制心跳间隔和重试策略（比如指数退避）
- 服务端只需响应空
$data，调用$connection->pong()即可，逻辑轻量且无副作用
Nginx / SLB 等中间件只认“有数据流动”，不认“连接还开着”
哪怕 Workerman 进程一直 running，只要 TCP 连接上 60 秒没任何帧（包括 Ping），Nginx 就会发 RST 终止连接，错误不会透传到 PHP 层，onClose 里看到的 $code 往往是 1001 或 0，日志里也没有 warning。
这时候如果靠服务端“想起来发个 Ping”，已经晚了——连接早就被中间设备掐断，发不出去。必须由客户端主动维持数据流，才能让整条链路“活着”。
Webman 的 onMessage 中判断空字符串是 Ping 帧的唯一可靠方式
WebSocket 协议规定：Ping 帧 payload 可为空，且服务端收到后必须回 Pong 帧（不是文本消息）。Workman/Webman 不自动处理，所以你必须显式拦截：
if ($connection->isWebSocket() && $data === '') {
$connection->pong();
return;
}
别写成 $connection->send('pong')，那是普通文本，客户端 WebSocket 实例不会把它当协议响应，心跳检测就失效了。
真正容易被忽略的是：这个判断必须放在所有业务逻辑之前，且不能被 try/catch 吞掉 —— 一旦抛异常，$connection->pong() 就不会执行，下一次心跳超时就断连。
