webman本身不是sdk而是php框架，需用其构建服务端并配合客户端sdk实现im；websocket必须在start.php手动new worker监听，启用pcntl/posix扩展，显式注册onconnect/onmessage/onclose回调，自行管理uid连接映射与跨进程广播。
Webman 本身不是 SDK，而是 PHP 框架（基于 Workerman/Swoole），你无法“用 Webman 开发一个 SDK”——真正要做的，是用 Webman 实现服务端逻辑，再配合前端/客户端 SDK（如 Easemob、Socket.IO 客户端、或自研轻量 client）完成端到端通信。所谓“高性能 IM SDK”，实际是服务端高可用 + 客户端协议轻量 + 连接复用 + 状态可追溯的组合结果。
WebSocket Worker 必须手动 new，不能只改 config/server.php
Webman 的 config/server.php 只控制 HTTP Worker，对 WebSocket 完全无效。所有 WebSocket 逻辑必须在 start.php 末尾、Worker::runAll() 之前显式初始化：
- 监听
websocket://0.0.0.0:2345（避开 HTTP 默认端口8787） - 必须调用
$worker->onConnect、$worker->onMessage、$worker->onClose，缺一不可；否则连接建立成功但收不到任何数据 - 确保 PHP 已启用
pcntl和posix扩展，否则 Worker 启动失败且无明确报错 - 浏览器控制台报
WebSocket connection to 'ws://...' failed，90% 是因为没走start.php这一步，而非代码写错
uid → connection 映射必须自己管，别依赖 $worker->connections
$worker->connections 是 raw socket 列表，不含业务身份，直接遍历它广播会推给未登录、已断连、甚至伪造连接的脏句柄。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 在
onConnect中解析 URL query（如?uid=123&token=abc）或 header token，校验通过后存入全局数组：$worker->uidConnections[123] = $connection - 务必在
onClose中执行unset($worker->uidConnections[$uid])，否则内存泄漏 + 消息误推 - 跨进程广播时，
$worker->uidConnections失效——必须用 Redis Pub/Sub 或Worker::$pidMap配合sendToAll()，不能只靠单机数组 - 群聊广播时，避免
foreach ($worker->connections as $conn)，改用foreach ($worker->uidConnections as $conn)，跳过无效连接
消息广播卡顿？先 encode 再复用，别在循环里 json_encode()
万级在线时，一次群聊广播若在 foreach 中反复 json_encode($msg)，CPU 会陡增；更糟的是，逐个 $conn->send() 在网络差时会阻塞整个 worker。
- 提前执行一次
$payload = json_encode($msg)，循环中直接$conn->send($payload) - 敏感操作（撤回、已读）必须带服务端生成的
seq和timestamp，防止客户端伪造或乱序 - 大消息建议拆包：先发 header（含
msg_id、type、seq），再发 payload，前端按序组装，降低单次 send 负载 - 连接数超 5000 时，强制按租户/部门哈希分组，只向目标组广播，而非全量遍历
离线消息和状态同步不能走内存，必须下沉到 Redis
Webman 单机内存存状态，多实例部署后必然消息不一致、状态丢失——这是企业级 IM 最常见的隐性崩点。
- 用户在线状态用
Redis SETEX online:{uid} 60 "1"，配合 KEYSPACE 通知或定时扫描清理 - 群成员关系用
Redis ZSET group:{gid} last_active_time {uid}，方便剔除长期不活跃成员 - 离线消息必须异步落库：WebSocket 收到消息后只写 Redis Stream 或 Kafka，由独立消费者进程落 MySQL/SQLite
- 历史消息查询禁用
OFFSET分页，必须用游标（cursor）+created_at + id复合索引
真正的高性能不在框架选型，而在连接怎么分、状态怎么存、消息怎么路由——Webman 做得最稳的，是把协议编解码和连接生命周期管住；其余部分，该甩给 Redis 就甩，该拆微服务就拆，别让它背全量架构债。
