websocket连接id不可靠，因其随页面刷新、网络抖动等频繁变更；客服分配必须基于redis存储的稳定坐席状态（如agent_id）和原子操作（setnx、publish）实现会话绑定与转接闭环。
WebSocket 本身不负责分配或转接，这些必须由业务层实现；直接依赖 ws 或 Spring WebSocket 的连接对象做“自动分配”，一定会在并发、掉线、重连时出错。
为什么不能靠 WebSocket 连接 ID 做客服分配
WebSocket 连接是临时的、无状态的。用户刷新页面、网络抖动、浏览器休眠都会导致连接断开并重建，socket.id（如 ws 库生成的）随之变化；而客服坐席的业务身份（如 agent_id）必须稳定可追溯。若把分配逻辑耦合在连接生命周期里，会出现：
- 同一用户多次刷新，被分给不同客服，会话上下文断裂
- 客服点击“小休”后仍收到新会话，因为服务端没及时感知其状态变更
- 两个用户几乎同时接入，
SETNX未加锁导致重复分配到同一客服
用 Redis 实现原子化会话分配的关键操作
所有分配决策必须基于外部状态存储，Redis 是最常用选择——它支持原子命令、过期控制、Pub/Sub 通知。关键不是“存数据”，而是怎么用对命令：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 坐席状态用
HMSET agent:1001 status idle skills "['tech','refund']" currentLoad 0，配合EXPIRE agent:1001 300防止脏数据残留 - 新会话分配时，先用
SCAN 0 MATCH agent:*拉取在线坐席列表，再在应用层按策略筛选（如优先currentLoad == 0且含匹配技能） - 最终绑定使用
SETNX session:S123456789 assignee 1001，成功才继续推送；失败则重试或进队列，绝不 fallback 到内存 Map - 分配成功后，立刻
PUBLISH channel:assign {"session_id":"S123456789","agent_id":1001}通知管理后台更新 UI
消息转接时如何避免“双写不一致”
转接不是简单改个字段，而是会话所有权迁移。常见错误是只更新数据库、忘了同步 WebSocket 连接状态，结果用户消息仍发往原客服通道。正确做法是三步闭环：
- 前端触发转接请求后，服务端先向原客服连接发送
{"type":"transfer_out","session_id":"S123456789","to_agent":2002}，强制其关闭该会话本地通道 - 再向目标客服连接发送
{"type":"transfer_in","session_id":"S123456789","user_info":{...}}，附带最近 5 条消息快照 - 最后更新 Redis 中的
session:S123456789的assignee字段，并设置EXPIRE防止长期滞留
漏掉任意一步，就可能出现用户发消息后“石沉大海”或“两边都收到”的情况。真正的难点不在 WebSocket 推送本身，而在转接过程中对连接、缓存、持久化三者的时序控制。
