不能用PHP数组存fd→uid映射，因其仅限单进程可见、多Worker时映射隔离且无法跨进程共享，易致消息错发或推送失败；Redis因跨进程共享、支持自动清理与高可靠性成为最稳妥选择。
为什么不能用 PHP 数组存 fd → uid 映射
PHP 数组（比如 $fdToUid = []）在单 Worker 进程内读写极快，但它是纯内存结构，只对当前进程可见。当你启用了多个 Worker（worker_num > 1），每个 Worker 都有自己的数组副本，彼此完全隔离。用户 A 在 Worker 1 登录时被映射为 fd:100 → uid:123，Worker 2 根本不知道这个关系；等你从 Worker 2 尝试推送消息，$server->push(100, $msg) 会直接失败——因为 100 这个 fd 在 Worker 2 的连接列表里根本不存在。
更危险的是：如果没做清理，Worker 1 崩溃后，fd 100 被操作系统回收、复用给新连接，而旧的数组映射还留着，就会导致消息错发或 fd[100] is not a valid connection 报错。
Redis 是多 Worker 下最稳妥的存储选择
必须用跨进程、跨机器可共享的存储来统一维护 uid ↔ fd 双向映射。Redis 是目前 PHP 生态中最常用、最轻量、也最可控的方案：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
SET user:123 fd:100存用户 ID 到 fd 的单向映射（适合私聊查找目标 fd） -
HSET fd:100 uid 123 ip "192.168.1.5" login_time 1725214140存 fd 元信息（适合 onClose 时反查 uid 并清理） - onOpen 时写入，onClose 时用
DEL user:123+DEL fd:100彻底清除，避免僵尸映射 - 推送前务必调用
$server->exist($fd)二次校验，防止 Redis 还没删干净但连接已断
Swoole\Table 能用，但有硬限制
如果你确认永远只部署单机、且 Worker 数量固定、连接数可预估，Swoole\Table 是比 Redis 更低延迟的选择，但它不是万能的：
- 必须在 Server 启动前就定义好字段和大小，比如
size = 65536，扩容需重启服务 - 不支持嵌套结构，存不了复杂元数据（如登录时间、设备类型），只能做简单 key-value 映射
- 无法跨机器，多节点部署时仍要搭配 Redis 或其他中心化存储
- 没自动过期机制，onClose 忘记
$table->del($fd)就会内存泄漏
推送时怎么安全地用 fd
拿到 uid 后查出 fd，只是第一步。实际 $server->push() 前还有三道关卡：
- 查 Redis 得到
fd后，先检查是否为空或过期（GET user:123返回 nil？） - 调用
$server->exist($fd)，返回 false 就说明连接已断，立刻跳过 - push 失败时捕获异常或判断返回值：
if ($server->push($fd, $data) === false) { // 记日志并清理 Redis 中该 fd } - 别依赖
$server->connections遍历——它只返回当前 Worker 的 fd 列表，多 Worker 下天然漏推
真正麻烦的从来不是“怎么存”，而是“什么时候删”和“删没删干净”。一个没清理的 fd 映射，可能让消息发到空连接、触发警告、甚至拖垮整个 Worker 进程的内存。
