workerman需自行维护client_id↔$connection映射：客户端首次连接后发送bind消息，服务端存入静态数组或worker属性并绑定client_id；http接口须通过channel发布指令，websocket进程订阅后查映射并send。
Workerman 本身不提供开箱即用的「按用户 ID 推送」能力，必须自己维护 client_id 到 $connection 实例的映射关系。直接用 $connection->id 推送会失败——它每次重连都变，没法绑定业务身份。
怎么建立 client_id ↔ connection 的映射
核心是：客户端首次连接后，主动发一条绑定消息（比如 {"type":"bind","client_id":"u1001"}），服务端收到就存进全局数组，并把 client_id 反向挂到连接对象上。
- 映射必须用静态变量或全局 Worker 属性（如
$worker->client_map），不能用局部变量，否则回调一结束就丢了 - 要处理重复登录：同一
client_id再次绑定时，先 unset 旧连接，避免旧连接残留导致消息发错 - 记得在
onClose回调里清理映射，否则断连后内存泄漏、推送命中已失效连接 - 如果用了 GatewayWorker 架构，映射必须存在
Register或BusinessWorker进程里，且需配合Channel跨进程同步（HTTP 接口通常不在同一个进程）
怎么从 HTTP 接口触发向指定 client_id 推送
HTTP 请求无法直接访问 WebSocket 连接对象，所以不能在控制器里写 $connection->send()。必须走中间层通信：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 最简方案：用
Channel（Workerman 自带）做进程间消息队列，HTTP 进程 publish['target_id'=>'u1001','msg'=>'hello']，WebSocket 进程 subscribe 后查映射表并发送 - 更稳方案：把映射存 Redis（如
redis:hset ws:clients u1001 $connection_id），HTTP 接口查 Redis 获取目标连接所在的 worker 进程号，再用Worker::getEventLoop()->add()或Channel转发 - 别用文件或数据库存映射——高并发下 I/O 成瓶颈，且查不到实时连接状态
为什么 send() 没反应？常见掉坑点
即使映射建对了，$connection->send() 仍可能静默失败，原因往往不是代码逻辑，而是连接状态或协议细节：
-
$connection->send()前没检查$connection->isConnected()，已断开的连接调用 send 不报错但无效 - 消息不是字符串或二进制：Workerman 要求
send()参数必须是 string 或binary，传 array 会直接忽略（得先json_encode()） - WSS 场景下用了自签名证书但客户端没信任，握手成功但后续 send 失败（现象是前端 onmessage 收不到，也无 error）
- Worker 进程数 > 1 时，HTTP 和 WebSocket 不在同个进程，却直接在 HTTP 里尝试访问
$worker->client_map—— 这个数组只在 WebSocket 进程里有数据
Webman 用户注意：不能直接复用 Workerman 示例代码
Webman 是基于 Workerman 的框架，但它的 WebSocket 是通过独立 process 启动的，config/process.php 里注册的 ws 进程和 HTTP 进程完全隔离：
- 你不能在
app/controller/MsgController.php里写$worker->client_map['u1001']->send()，那个$worker对象根本不存在 - 必须用
Channel+ Redis 组合：HTTP 进程往 channel 发指令，ws 进程监听后查 Redis 映射表，再调用send() - 心跳检测要自己加（比如每 30 秒
$connection->ping()），不然 Nginx 或云厂商 LB 会主动断开空闲连接，导致映射表里存着已失效的$connection
真正难的不是“怎么写 send”，而是怎么让不同进程、不同生命周期的对象，在不耦合的前提下可靠地找到彼此——映射存哪、谁来维护、断连怎么清理、跨进程怎么通知，每个环节漏一环，推送就不可靠。
