onclose延迟或不触发的根本原因是网络层未及时通知内核断开事件，如nat防火墙回收空闲连接或客户端强杀进程导致fin包缺失；必须通过应用层心跳+定时主动探测（如每25秒发ping、45秒超时close）并避免onmessage阻塞来解决。
onClose 为什么延迟触发或完全不触发
根本原因不是 Workerman 框架本身有问题，而是连接断开时网络层没及时通知内核，导致 PHP 进程无法感知。常见于 NAT 网关、代理、防火墙主动回收空闲连接，或客户端进程被强杀（如 Android 杀后台、iOS 切后台后 WebSocket 被系统静默关闭），此时 TCP FIN 包根本没发出来，服务端就一直等不到断开信号。
如何验证是真断开还是假“挂起”
先确认是否真的断开了，而不是卡在半开状态：
- 用
netstat -an | grep :端口号查看连接状态：如果显示ESTABLISHED但客户端已关机，大概率是假在线 - 在
onMessage里加日志，连续 30 秒没收到任何数据，说明连接可能已失效但未触发onClose - 用
tcpdump -i any port 端口号抓包，看是否有 FIN 或 RST 包——没有就说明断开行为没透传到服务端
必须手动加心跳 + 主动探测才能补救
Workerman 不自带连接活性检测，onClose 完全依赖底层 socket 事件，所以你要自己做两件事：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 服务端每 25 秒发一次心跳（例如
$connection->send('ping')），并用$connection->lastPingTime = time()记时间戳 - 启动一个全局定时器（
Timer::add(10, function () { ... })），遍历所有连接，对time() - $connection->lastPingTime > 45的连接调用$connection->close() - 客户端收到
ping必须立刻回pong，否则下次心跳超时就会被踢；别用WebSocket.prototype.ping（浏览器不支持），直接ws.send('pong')
注意 onMessage 里不能阻塞，否则 onClose 永远不执行
如果 onMessage 回调里做了同步 IO（比如 file_get_contents、sleep、没设超时的 curl），整个 Worker 进程会卡住，后续所有事件（包括 onClose）全部积压，直到该回调返回。真实线上案例中，有人在 onMessage 里调用了一个没设 timeout 的 Redis get，结果 Redis 故障时所有连接的 onClose 延迟了 5 分钟以上才批量触发。
解决方法只有两个：onMessage 内禁止同步阻塞操作；必须 IO 就用异步 client（如 workerman/redis 的 async 版本）或投递到 TaskWorker。
