Workerman服务端不自动重连，需客户端实现重连并服务端配合会话管理；须用client_id+connection_id双标识、Redis Hash存储带过期时间的会话、握手阶段校验认证包、定时心跳检测与清理。
Workerman连接断开后不会自动重连，必须手动实现
Workerman本身是常驻内存的PHP进程框架，Worker 启动后会持续运行，但客户端（如浏览器 WebSocket 或移动端长连接）断线时，onClose 会被触发，而服务端不会“感知”到重连需求——它根本不知道客户端要回来。所谓“自动重连”，本质是客户端行为；服务端只需保证连接建立逻辑健壮、会话可恢复、不因重复连接出错即可。
常见错误现象：onConnect 中未校验重复登录导致旧连接残留、onClose 未清理关联资源（如 Redis 订阅、定时器）、客户端反复重连却不断开旧连接，最终耗尽 worker 进程的 socket 句柄或内存。
- 所有新连接必须带唯一
client_id（如 UUID 或设备+用户组合），服务端用$connection->id+client_id双维度标识会话 - 在
onConnect中查 Redis 判断该client_id是否已在线，若存在则主动close旧连接（避免“一账号多端互踢”逻辑失效） - 在
onClose中务必调用unset($this->clients[$client_id])并删除 Redis 中对应 key，否则下次重连时会误判为“已在线”
WebSocket连接中如何安全传递和校验client_id？
不能依赖 URL 参数传 client_id（易被篡改、不支持二进制协议），也不能在 onMessage 首帧才发（此时连接已建立，无法拒绝非法接入）。正确做法是在 WebSocket 握手阶段通过 onWebSocketConnect 拦截并解析 Sec-WebSocket-Key 外的自定义 header，或更稳妥地：强制客户端在首次 onMessage 必须发送带签名的认证包。
使用场景：SDK 初始化后第一帧消息必须是 {"type":"auth","token":"xxx","client_id":"xxx"}，服务端验证通过才接受后续消息，否则立即 $connection->close()。
- Token 应含时间戳和签名（如 HMAC-SHA256(
client_id+timestamp+$secret)），防重放 - 验证失败时不要返回错误详情，只关闭连接，避免暴露校验逻辑
- 校验通过后把
client_id绑定到$connection实例上：$connection->client_id = $data['client_id'];
心跳超时与客户端重连策略必须协同设计
Workerman 默认不处理心跳，ping/pong 需手动收发。如果只靠客户端单方面发 ping，服务端不响应 pong 或不检测超时，连接可能长时间假死（TCP 层未断，但业务层已不可用）。
性能影响：频繁心跳会增加连接负载；心跳间隔过长又会导致故障发现延迟。建议服务端每 30 秒发一次 ping，客户端收到后必须回 pong；若 60 秒内无响应，服务端主动 close 连接。
- 在
onConnect中启动定时器：$connection->ping_timer = Timer::add(30, [$connection, 'send'], ['ping']); - 在
onMessage中识别pong并清除上次 ping 的标记（可用$connection->last_pong = time()记录） - 在
onClose中用Timer::del($connection->ping_timer)清理定时器，防止内存泄漏
Redis 存储连接映射时要注意数据结构选型
不能用 SET client_id connection_id 简单存储，因为 Workerman 进程重启后 connection_id 会变，且单个 client_id 可能跨多个 Worker 进程连接。必须用支持分布式、带过期时间的数据结构。
推荐方案：用 Redis Hash 存储 client_id → {worker_id, connection_id, last_active}，并配合 EXPIRE 设置 2 小时过期；同时用 Redis Pub/Sub 做跨进程广播（如踢人指令）。
- 写入时用
hSet+expire两步，避免竞态（可封装成 Lua 脚本原子执行） - 查询时用
hGetAll获取完整信息，不要只取connection_id，否则无法判断是否跨进程 - 不要用
keys client_*扫描，高并发下会阻塞 Redis，改用scan游标分批处理
最易被忽略的是：客户端重连成功后，旧连接的 onClose 可能晚于新连接的 onConnect 触发，导致 Redis 中短暂出现两个同 client_id 的记录。必须在新连接写入前加 Lua 脚本校验并清理旧值，不能靠应用层 if-else。
