workerman 区分客户端靠连接id、业务绑定uid、gatewayworker注册机制三种方式：$connection->id是进程内唯一整数id；需客户端首次上报uid并存入redis映射表；gatewayworker则通过registeruid自动管理多端登录与推送。
Workerman 5.2.3 区分不同客户端连接，核心靠连接对象的唯一标识和业务层的主动绑定逻辑，不是靠 IP 或端口做判断（它们可能复用或被代理遮蔽），也不是靠 session（HTTP 的那一套在长连接里不自动生效）。
以下是最常用、最可靠、生产环境普遍采用的三种方式：
连接 ID（$connection->id）是基础身份凭证
每条 TCP/WebSocket 连接被 Workerman 接入时，会自动生成一个全局唯一的整数 ID（进程内唯一，多进程下需配合外部存储做全局去重）。这个 ID 存在 $connection->id 中，稳定、轻量、无需额外维护。
- 它在
onConnect回调中即可获取，整个连接生命周期不变； - 可直接用于单进程内精准推送：
$worker->connections[$conn_id]->send(...)； - 注意：多进程部署时，不同 worker 进程的
$connection->id可能重复，所以不能跨进程直接用它做全局路由。
绑定 client_id 或 uid 实现业务身份识别
真正区分“谁在连”，必须由客户端在首次通信时上报身份（如登录态 token、用户 ID、设备编号等），服务端解析后与当前连接绑定。常见做法：
- 客户端连接成功后，立即发一条 JSON 消息，例如
{"type":"auth","uid":1001,"token":"abc"}； - 服务端在
onMessage中识别该类型，校验通过后将uid写入连接对象：$connection->uid = 1001； - 同时存入全局映射表（推荐 Redis Hash 或内存数组+锁）：
$redis->hSet('online_users', $uid, $connection->id)； - 后续所有推送（如“给用户 1001 发消息”）先查表得连接 ID，再投递。
⚠️ 不要只依赖 IP + 端口组合来识别用户——NAT、代理、移动端复用连接都会导致误判；也不要仅靠 cookie 或 header，WebSocket 升级请求之后这些上下文就断开了。
使用 GatewayWorker 时走 registerUid/registerRoute 流程
如果你用的是 GatewayWorker（推荐生产环境），它已封装好用户维度的连接管理：
- 在
BusinessWorker中调用$client_info['uid'] = $uid并返回，GatewayWorker 会自动执行registerUid($connection->id, $uid)； - 之后可通过
Gateway::sendToUid($uid, $msg)直接推送，底层自动查找该 uid 所有在线连接； - 支持单 uid 多端登录（多个 connection），也支持踢下线、广播给某群组等高级路由。
本质上，Workerman 不替你决定“谁是谁”，它只提供连接容器和 ID；区分客户端，是你在业务逻辑里完成的一次主动注册动作——就像给刚进门的人发一张带编号的门禁卡，而不是靠他穿什么衣服认人。
