workerman 启动后收不到客户端消息，需检查 onmessage 是否正确注册；单聊须用登录态绑定用户 id 而非 $connection->id；群聊避免 foreach 广播，应使用 sendtoall 或拆分进程；消息时序与去重需依赖外部存储或时间戳+序列号机制。
Workerman 启动后收不到客户端消息？检查 onMessage 是否被正确注册
Workerman 不是传统 Web 服务器，它不解析 HTTP 请求体里的 POST 数据或 WebSocket 消息自动转对象——所有二进制或文本数据都原样传给 onMessage 回调。如果你用浏览器 WebSocket 连上 ws://127.0.0.1:2346 却发不出消息，大概率是服务端没写 onMessage，或写了但没绑定到正确的 Worker 实例。
常见错误：在 Worker::runAll() 前漏掉 $worker->onMessage = function($connection, $data) { ... };；或者把逻辑写在了 onConnect 里；又或者用了 TextProtocol 却发 JSON 字符串但没加换行符（\n），导致协议解析失败。
实操建议：
- 确认使用的是
WebsocketWorker（推荐）而非Worker+TextProtocol，前者直接支持标准 WebSocket 帧，兼容浏览器原生WebSocketAPI -
onMessage中先var_dump($data)看是否收到原始字符串，再用json_decode($data, true)解析——注意判断返回值是否为null，避免静默失败 - 不要在
onMessage中做阻塞操作（如同步 MySQL 查询、sleep()），否则会卡住整个进程的消息循环
单聊怎么识别对方连接？用 $connection->id 不可靠，得靠登录态绑定
$connection->id 是 Workerman 内部生成的递增整数，重启服务就重置，且不同进程间不唯一，不能当用户 ID 用。单聊必须让客户端在连接建立后主动上报身份（如 {type: 'login', user_id: 1001}），服务端解析后存到全局映射表里。
实操建议：
- 用 PHP 的
static数组或Swoole\Table（若已装 Swoole 扩展）存映射：user_id → $connection，注意并发写入要加锁（pcntl_fork下各进程独立内存，需用Redis或MySQL做中心存储） - 群聊同理，但映射结构是
group_id → [conn1, conn2, ...]；单聊消息转发时，先查$connections[$target_user_id]是否存在，再调用$connection->send() - 客户端断开时，务必在
onClose中从映射表里删掉对应项，否则会出现“用户在线但收不到消息”的假象
群聊广播性能崩了？别用 foreach 遍历所有连接发消息
当群成员超 500 人，用 foreach ($group_connections as $conn) { $conn->send($msg); } 会明显拖慢响应——不是因为循环本身慢，而是每次 send() 都触发一次内核 socket 写缓冲区拷贝，且 Workerman 默认单进程处理所有连接，高并发下容易积压。
实操建议：
- 改用
ConnectionInterface::sendToAll()（需传入连接数组）或更优的Worker::$connections全局迭代器配合条件过滤（但注意它包含所有连接，得自己筛出目标群成员） - 对大群启用「消息合并」：把几秒内的多条消息拼成一个 JSON 数组再广播，减少帧数量（适合通知类场景，非强实时聊天慎用）
- 真正扛量的做法是拆分群：按
group_id % worker_count把群分配到不同 Worker 进程，每个进程只管一部分群，避免单点瓶颈（需配合 Redis 存储群成员关系）
消息顺序乱了、重复了？Workerman 不保证跨连接消息时序
Workerman 的事件循环是单线程的，同一进程内 onMessage 调用是串行的，但如果你开了多个 Worker 进程（$worker->count = 4），不同进程收到消息的时间不可控，A 进程处理用户 X 发的消息、B 进程同时处理用户 Y 发的消息，最终广播顺序取决于哪个进程先完成，和发送时间无关。
另外，客户端网络抖动重连后，可能重复发送未确认消息，服务端若无去重机制就会出现双发。
实操建议：
- 强制全局时序：所有消息经由一个「消息队列」（如 Redis Stream 或 Kafka）中转，由单独消费者进程按序分发，代价是引入外部依赖和延迟
- 轻量级方案：在消息体里带上客户端本地毫秒时间戳 + 自增序列号（
{ts: 1718923456789, seq: 123, msg: 'hi'}），接收方按ts+seq排序渲染（注意时钟漂移，可用服务端统一授时接口签发） - 去重靠消息 ID：客户端每发一条生成 UUID，服务端用 Redis
SETNX缓存 5 分钟，命中即丢弃——前提是消息体里明确带msg_id字段
真正的难点不在代码长短，而在状态落地的位置：连接生命周期、用户身份、群成员关系、消息时序、离线存储——这些都不能只存在 PHP 变量里。Workerman 是胶水，粘得住 TCP，粘不住业务一致性。
