workerman中广播“正在输入”状态需基于会话id精准投递：在onconnect绑定$connection->uid和$connection->session_id，收到typing消息后遍历$worker->connections，筛选出session_id匹配且uid不等于发送方的连接，确认isconnected()后send；须配合onclose清理映射及心跳机制防残留。
Workerman 中如何广播“正在输入”状态给指定会话
“正在输入…”提示本质是客户端 A 发送一个状态事件（比如 typing: true），服务端收到后只推送给同个会话的另一方（B），而不是全站或所有客服。Workerman 默认不维护会话关系，必须自己绑定用户 ID 与连接实例，并按会话维度路由消息。
关键不是发消息，而是「精准投递」：客服 A 给用户 B 打字时，状态只通知 B 的连接，不能误推给 C 或其他客服。
- 每个连接在
onConnect里绑定唯一标识：$connection->uid = $user_id（用户 ID）和$connection->session_id = $sid（会话 ID，如"user_123-cs_456"） - 状态消息体建议含字段：
{"type":"typing","session_id":"user_123-cs_456","is_typing":true,"timestamp":171xxxxxx} - 服务端收到 typing 消息后，查所有连接，筛选出
$conn->session_id === $msg['session_id'] && $conn->uid !== $sender_uid的那个连接再 send
为什么不能用 Workerman 的 broadcast() 或 onMessage 全局处理
broadcast() 会把消息发给所有连接，导致用户看到“客服在给别人打字”，或者客服看到“多个用户同时输入”，完全错乱。而裸写 onMessage 不做 session 路由，就是把 typing 当普通消息 echo 回去，起不到提示作用。
常见错误是把 $connection->send() 写在 onMessage 顶层，没加任何过滤：
// ❌ 错误：所有人都收到
foreach ($worker->connections as $conn) {
$conn->send($msg);
}
正确做法是先提取 session_id，再遍历连接匹配目标：
// ✅ 正确：只推给会话另一方
$target_conn = null;
foreach ($worker->connections as $conn) {
if ($conn->session_id === $session_id && $conn->uid !== $sender_uid) {
$target_conn = $conn;
break;
}
}
if ($target_conn && $target_conn->isConnected()) {
$target_conn->send(json_encode(['type'=>'typing', 'is_typing'=>true]));
}
前端如何控制“正在输入…”的显示与自动取消
前端不能一收到 typing: true 就立刻显示，否则用户快速打字会反复触发，造成闪烁；也不能等用户停手再发 false，因为网络延迟或断连会导致“正在输入…”卡住不消失。
- 客户端每开始输入（
input或keydown）就发一次{type:"typing", is_typing:true}，并启动一个 3 秒倒计时 - 倒计时内再次输入，就 clearTimeout 并重置新定时器；3 秒无操作，自动发
is_typing:false - 收到
is_typing:true后，清空旧定时器，显示提示，并启动本地 5 秒隐藏倒计时（防网络抖动） - 5 秒内没再收新
true，就隐藏提示——这个超时要略长于后端下发 false 的预期延迟
注意 connection 断开时的 session 状态残留问题
Workerman 不自动清理断连的 $connection 对象，如果用户关浏览器、切后台或弱网断开，$connection->isConnected() 可能仍返回 true，导致 typing 消息发到已失效连接，甚至引发 Connection reset by peer 报错。
必须配合心跳检测或 onClose 清理：
- 在
onClose里 unset 掉该连接的session_id映射（如果你用了全局数组缓存会话连接） - 避免在循环中直接调用
$conn->send()，先判断$conn->isConnected()，失败则 unset 连接引用 - 更稳妥的做法：用 Redis 存储活跃会话映射（
session_id → uid），每次发 typing 前查 Redis 是否还存在该会话，而非只依赖内存连接列表
实际跑起来你会发现，typing 提示是否及时、是否消失，80% 的问题不在发送逻辑，而在连接生命周期管理是否干净。
