$frame->fd 是获取客户端连接 ID 的唯一可靠方式，它在 onOpen 时分配且生命周期内不变；$req->fd 同样有效但为 protected 属性需显式访问；不可用 IP/UA 匹配或遍历 connections 获取，业务需自行维护 fd 与用户 ID 的映射。
$frame->fd 是唯一可靠、直接可用的获取方式，其他任何“猜 fd”“查连接池”“遍历 $server->connections”都属于绕路或错误前提。
onMessage 回调里直接读 $frame->fd
WebSocket 消息事件中，Swoole 会把完整帧对象传给回调函数，$frame 的 fd 属性就是当前发送消息的客户端连接 ID：
- 它在
onOpen时已分配，整个生命周期内不变（除非连接断开重连） - 它不是自增 ID，也不保证连续，但对当前服务器进程绝对唯一
- 不要试图用
$_SERVER['REMOTE_ADDR']或请求头还原 fd —— HTTP 层信息在 WebSocket 握手后就不可靠了
示例：
function onMessage(swoole_websocket_server $server, swoole_websocket_frame $frame) {
$fd = $frame->fd; // ✅ 正确
$data = $frame->data;
var_dump("收到 fd {$fd} 的消息: {$data}");
}
onOpen 里拿不到 $req->fd？其实是能的
部分人误以为 $req 对象没 fd，其实有 —— 但得用 $req->fd，不是 $req->get['fd'] 或其他字段：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
$req->fd在onOpen时就已存在，和$frame->fd值一致 - 这个
fd是 Swoole 内部 socket 句柄，不是用户传的参数，不能被伪造或覆盖 - 如果用
var_dump($req)看不到fd，是因为它是 protected 属性，需显式访问
正确写法：
$server->on('open', function (swoole_websocket_server $server, swoole_http_request $request) {
$fd = $request->fd; // ✅ 不是 $request->get['fd']
echo "新连接 fd: {$fd}\n";
});
别用 $server->connections 遍历找 fd
$server->connections 是一个迭代器，返回所有活跃 fd，但它不提供上下文映射，纯属“知道有哪些 fd”，不是“哪个 fd 发了这条消息”：
- 你无法从
$frame->data反推是谁发的，只能靠$frame->fd - 遍历
$server->connections再比对 IP/UA 来“匹配 sender”是典型误区 —— 多个客户端可能同 IP，UA 可伪造，且性能极差 - 该迭代器在高并发下还可能触发 warning：「Connection iterator is not safe in async mode」
fd 和用户 ID 绑定必须自己做，Swoole 不管
Swoole 只管网络层连接，fd 是临时句柄，不等于用户身份。想按用户推送，必须主动建立映射：
- 常见做法：客户端登录后发
{"type":"login","uid":123}，服务端存$fdToUid[$frame->fd] = $uid - 必须在
onClose中清理映射，否则内存泄漏 + 推送错人 - 单机可用全局数组，多机部署必须用 Redis，不能依赖
fd跨机器识别用户
关键点：fd 本身无业务意义，它的价值只在于“此刻这个连接还活着”，所有业务逻辑都要基于你自己的 uid/fd 映射表来转译。
