Workerman协程中长连接心跳失效需显式启用Swoole协程支持，心跳定时器须在onWorkerStart中用go()启动并使用co::sleep()，响应需协程IO发送，时间戳用microtime(true)判定活跃度，禁用协程sleep抢占以保障间隔精准。
Workerman协程中处理长连接心跳失效，会导致NAT超时、防火墙断连或客户端感知“假在线”，进而引发消息丢失、重连风暴或连接堆积。
确认是否真在协程环境运行
Workerman默认不启用协程，【必须显式启用Swoole协程支持】，否则所有`go()`、`co::sleep()`、协程MySQL/Redis客户端均无效，心跳逻辑实际仍在同步阻塞模式下执行。
检查启动脚本是否包含：`define('SWOOLE_HOOK_ALL', true);` 且 Workerman 版本 ≥ 4.1.0，Swoole 版本 ≥ 4.8.0；若使用 `workerman/workerman` 官方包而非 `workerman/swoole`，则协程根本未加载。
运行 php -m | grep swoole 确认 Swoole 扩展已启用，并检查 php --ri swoole 中 `enable_coroutine => On` 是否为 true。
心跳定时器必须挂载到协程上下文
方法一：在 onWorkerStart 中用 go() 启动独立协程定时器
第一步：在 Worker 实例的 onWorkerStart 回调里启动心跳检测协程，不能放在 onConnect 里——后者每次连接触发一次，会创建海量协程导致内存溢出。
第二步：使用 co::sleep(30) 替代 sleep(30)，否则整个 Worker 进程将被阻塞，所有连接冻结。
第三步：遍历 $worker->connections 时，需加锁或使用 ConnectionManager 的线程安全读取方式，避免协程并发读写导致连接对象状态错乱。
心跳响应必须走协程IO通道
方法一：客户端发 ping → 服务端 onMessage 拦截 → 协程内异步回 pong
收到 {"type":"ping"} 时，不要直接调用 $connection->send()，该方法在协程环境下可能因底层 socket 写缓冲区满而阻塞当前协程。
应改用 go(function () use ($connection) { $connection->send('{"type":"pong"}'); });，确保发送操作不阻塞主协程调度。
方法二：启用 Swoole 的协程 socket write 超时控制（仅限 Swoole 驱动）
在 Worker 构造前设置：ini_set('swoole.socket.send_timeout', '3');，避免某条慢连接拖垮整个心跳协程。
【切勿在 onMessage 中执行 PDO 查询或 file_get_contents 等同步IO】，这类操作会退出协程上下文，使后续心跳发送退化为同步阻塞，心跳间隔严重漂移。
连接活跃度判断必须基于协程安全时间戳
每个连接对象需绑定协程安全的时间戳字段：$connection->last_active_at = time();，但 time() 返回整数，在高并发下精度不足，易造成误判断连。
改用 $connection->last_active_at = microtime(true);，并在清理协程中对比：if (microtime(true) - $connection->last_active_at > 65.0)。
注意：PHP 的 microtime(true) 在协程切换时仍保持单调递增，无需额外加锁，是协程环境下最轻量的活跃判定依据。
关闭非必要协程抢占以稳定心跳节奏
Workerman + Swoole 默认开启协程抢占式调度（preemptive scheduling），这会导致心跳协程被频繁打断，实际间隔波动可达 ±200ms，触发 Nginx proxy_read_timeout 断连。
在 onWorkerStart 前添加：Co\Runtime::set(['hook_flags' => SWOOLE_HOOK_ALL & ~SWOOLE_HOOK_SLEEP]);，禁用协程 sleep 抢占，让 co::sleep(30) 真正精准休眠 30 秒。
这一步不做，心跳间隔可能在 22～38 秒之间随机抖动，而多数反向代理默认超时为 60 秒，两次抖动叠加即触发断连。
