必须用 websocket 实现打字状态，因其能毫秒级触达 typing 事件；轮询因 http 延迟、缓存等无法感知瞬时输入。前端需防抖（300ms true + 1500ms false），后端应独立处理 typing 元数据并超时自动清理。
打字状态为什么必须用 WebSocket 而不是轮询
因为轮询无法感知“正在输入”这个瞬时动作。用户按下键盘的那一刻，服务端就要立刻知道；松开后几秒内没发消息，状态就得自动清除。HTTP 请求有延迟、有缓存、有重试逻辑，根本做不到毫秒级响应。而 WebSocket 的 send() 是即时触达的，只要客户端发一条 { "type": "typing", "status": true, "to": "客服ID" }，服务端就能马上广播给目标客服端，UI 立刻显示「对方正在输入…」。
前端如何避免频繁触发 typing 事件导致抖动
用户敲字是连续行为，但你不该每按一次键就发一次 WebSocket 消息。真实场景下容易造成消息风暴和 UI 频繁闪烁。
- 用
setTimeout+clearTimeout实现防抖：监听input或keydown，每次触发先清掉上一个定时器，再设一个 300ms 延迟发送typing: true - 松开键盘后，再设一个 1500ms 定时器发
typing: false，模拟“停顿即结束”逻辑 - 仅当输入框内容长度 > 0 且焦点在输入框时才启用该机制，防止误触
- 如果当前 WebSocket 连接状态不是
OPEN，直接丢弃 typing 消息，不排队不重试
后端怎么识别并广播 typing 状态而不影响主聊消息流
typing 是轻量元数据，不能和业务消息（如聊天文本、图片链接）混在一个处理管道里。否则容易被消息队列积压、延迟甚至丢失。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 在服务端单独定义
typing类型路由或处理器，绕过消息持久化、审计日志等重逻辑 - 用内存 Map 或 Redis Hash 缓存每个用户最近一次 typing 时间戳，例如
typing:uid123 → { ts: 1747991283, to: "kf456" }，避免重复广播 - 广播前校验目标客服连接是否活跃（查
ws.readyState === OPEN或对应 fd 是否有效），跳过已断开连接 - 不走消息队列，直接调用
ws.send()推送，但要加 try/catch 防止因连接异常阻塞主线程
移动端弱网下 typing 提示失效的典型原因
微信小程序或 iOS Safari 中，typing 状态经常“卡住”或“不消失”，不是代码写错了，而是网络层干扰导致的。
- Nginx 默认 60s 关闭空闲 WebSocket 连接，若没心跳，typing 的 false 消息可能发不出去——务必配
proxy_read_timeout 300和客户端心跳 - 小程序要求 wss，但本地调试用 ws 协议时，
onClose事件可能不触发，导致 typing 状态滞留；上线前必须真机测 wss - iOS WKWebView 对
beforeunload事件支持差，页面切后台时不会主动发typing: false，得靠 visibilitychange + 定时器兜底 - 别依赖单次
typing: false，服务端应设置 2s 自动超时清理：如果 2s 内没收到新typing: true，就主动清空该用户的 typing 状态
typing 状态本质是“软提示”，它不参与会话一致性校验，也不需要 ACK 确认。真正容易被忽略的是：它对连接生命周期的敏感度远高于普通消息——一次未捕获的 onClose，就可能导致整个客服界面长期显示错误的「正在输入」。所以与其堆逻辑，不如从连接保活和状态兜底两个点死守。
