WebSocket服务端必须在onMessage而非onWorkerStart中处理业务逻辑，因onWorkerStart仅进程启动时执行一次，无法访问连接实例；正确做法是将收发消息、踢人、入房等操作全部置于onMessage、onConnect、onClose回调中，确保连接级操作隔离可靠。
WebSocket 服务端必须用 onMessage 而不是 onWorkerStart 处理业务逻辑
很多人把聊天消息广播逻辑写在 onWorkerStart 里，结果发现消息只发给部分连接，甚至完全不触发。这是因为 onWorkerStart 只在工作进程启动时执行一次，它不感知连接生命周期，也无法访问当前 $connection 实例。
正确做法是把所有连接级操作（收消息、发消息、踢人、房间加入）全部放在 onMessage、onConnect、onClose 回调中。这些回调由 Workerman 内核在连接上下文里自动调用，保证每个连接的操作隔离且可靠。
-
onConnect：适合做用户身份预检（如校验 token）、初始化连接状态（分配 ID、存入全局$connections表） -
onMessage：唯一合法的消息处理入口；接收到的数据默认是字符串，若前端发的是 JSON，需手动json_decode($data, true) -
onClose：务必在这里清理该连接关联的房间成员列表、Redis 在线状态 key，否则会累积脏数据
房间隔离不能靠全局数组，得用 Redis 的 SET + PUB/SUB 拆分流量
用 PHP 数组存房间成员（比如 $rooms['general'][] = $connection）在单进程下能跑通，但 Webman 默认多进程（$worker->count = 4），每个进程内存独立——A 进程里的 $rooms 对 B 进程不可见，广播就失效了。
真实高并发场景下，必须用外部存储做状态同步。Redis 是最轻量且合适的选择：
- 成员管理用
SMEMBERS room:general+SADD room:general $conn_id，避免自己维护数组一致性 - 跨进程广播用
PUBLISH channel:general $msg，每个 Worker 启动时SUBSCRIBE对应频道，收到后遍历本进程内匹配的连接再send() - 别用
GET/SET存整个房间消息历史，改用LPUSH chat:general $msg+LTRIM chat:general 0 999控制长度，防止内存爆炸
start.php 里设置 worker->count 不等于 CPU 核数 ×2 就翻车
Webman 的 Worker 进程是常驻内存的，每个进程独占一个 CPU 核心。设太多（比如 32 个进程跑在 4 核机器上），会导致频繁上下文切换，CPU 空转率飙升；设太少（比如只设 1），又无法压满多核，QPS 上不去。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
经验值是：$worker->count = cpu_count() * 2，但必须配合系统 ulimit 调整：
- 运行前执行
ulimit -n 65535，否则超过 1024 连接就会报Too many open files - 检查
/proc/sys/net/core/somaxconn是否 ≥ 65535，否则新连接被内核丢弃，现象是前端 WebSocket 连接反复pending - 禁用
start.php中的echo或var_dump，大量日志 I/O 会拖慢事件循环，实测 QPS 下降 40% 以上
前端重连必须带退避策略，否则服务端瞬间被打爆
WebSocket 断开后，前端如果立刻 new WebSocket(url)，在弱网或服务重启时，成千上万客户端会在 1 秒内发起重连请求，形成“重连风暴”，直接打满连接数限制。
必须实现指数退避（exponential backoff）：
- 首次失败后等 1 秒再连，第二次失败等 2 秒，第三次等 4 秒……上限封顶到 30 秒
- 每次重连前检查
document.visibilityState === 'visible'，页面切到后台时暂停重连 - 服务端在
onClose里不要立即删 Redis 成员，加个 30 秒过期的SETEX offline:$conn_id 30 1，前端重连成功后再DEL，避免误判掉线
真正卡住万人在线的，往往不是协议或框架本身，而是连接生命周期管理没闭环——连接进不来、消息发不出、断线清不净，三者任一出问题，负载就拐点式恶化。
