Swoole中WebSocket连接管理需避免直接用fd作用户ID，因其动态分配、无业务上下文且跨进程不唯一；应解析token映射uid，并通过exist()校验、sendMessage()跨进程推送、内置heartbeat机制保活，否则将导致内存泄漏与消息丢失。
WebSocket 在 Swoole 中不是“配个路由就能跑”的 HTTP 接口，它本质是长生命周期的 TCP 连接管理问题。直接用 $server->on('message', ...) 处理业务逻辑，不加连接跟踪和心跳清理，上线后内存持续上涨、连接数虚高、Connection reset by peer 错误频发——这不是配置问题，是架构认知偏差。
为什么 $server->connections 返回的连接 ID 不能直接当用户 ID 用
Swoole 的 $server->connections 是一个只读迭代器，返回的是当前活跃连接的 fd（文件描述符），它随每次 accept 动态分配，重启服务、客户端重连、负载均衡切换都会导致 fd 重置。它不携带业务上下文，也不保证唯一性跨进程。
- fd 只在当前 worker 进程内有效，多 worker 场景下不同进程可能有相同 fd 值
- 客户端断线重连后 fd 必然变化，但用户身份（如 uid）应保持一致
- 若用 fd 当 key 存用户数据到
$_SESSION或 Redis，会快速产生脏数据和内存泄漏 - 正确做法：在
onOpen回调中解析 WebSocket 握手请求的 query 参数或 cookie，提取uid或token，再映射到自定义连接表（如$this->clients[$uid] = $fd）
onMessage 中调用 $server->push() 为什么有时收不到消息
根本原因是 $server->push() 只支持向本 worker 进程内的 fd 发送数据。若客户端连接落在 worker #2，而业务逻辑被投递到 worker #1（比如通过 task 进程处理完再回调），此时用 $server->push($fd, ...) 就会静默失败，getLastError() 返回 EINVAL，但默认不抛异常。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 检查 fd 是否仍在线：必须先调用
$server->exist($fd)，否则对已关闭连接 push 会触发 warning - 跨进程推送必须走
$server->sendMessage()+onPipeMessage，或统一投递到 task 进程由其所在 worker 执行 push - 注意
$server->push()不支持批量，循环发送需控制频率，否则触发底层 send buffer 溢出，表现为部分消息丢失 - 调试时可在
onMessage开头加var_dump(getmypid(), $fd);确认当前进程与连接归属关系
如何安全地实现心跳检测与自动踢人
靠前端定时 ws.send('ping') + 后端 onMessage 判断内容是脆弱的：网络抖动、协程阻塞、消息堆积都可能导致假超时。Swoole 6.1.1 起推荐用原生心跳机制，而非手动维护时间戳。
- 启用内置心跳：配置
'heartbeat_idle_time' => 60, 'heartbeat_check_interval' => 25，单位秒 - 该机制不依赖业务层收发，由 reactor 线程在空闲时扫描连接 last_time，超时则主动 close fd
- 务必配合
onClose清理自定义连接表（如unset($this->clients[$uid])），否则$server->connections数下降但内存不释放 - 若需业务级心跳（如上报在线状态），应在
onMessage中识别ping/pong帧并更新$this->lastActiveAt[$uid]，再另起定时器扫描踢人，避免和内置心跳冲突
真正难的不是写通 onOpen/onMessage/onClose，而是理解每个 fd 背后是一个持续占用内存、文件句柄和 CPU 时间片的实体。连接数上万时，差一行 unset 或一次跨进程误用 push，就足以让服务在凌晨三点开始缓慢窒息。
