核心瓶颈在于缺乏统一的用户-连接映射与路由机制。需构建用户层（userid）、设备层（deviceid）、房间层（room:id）三级绑定，并通过redis外置存储会话关系，消息中必须携带type和target字段以实现精准投递。
WebSocket 多端同步的核心瓶颈在哪
不是连接建不起来，而是「同一用户在不同设备上线后，服务端不知道该把消息发给谁」。常见现象是：手机端发了一条消息，网页端收不到；或者用户登出旧设备，新设备却收不到后续更新。根本原因在于缺乏统一的用户-连接映射机制和路由上下文。
必须实现的三个路由层：用户、设备、房间
消息不能直接广播，得有明确投递路径。实际部署中需分三层绑定：
-
用户层：连接时通过
ws://host/ws?token=xxx携带认证凭证，服务端解析出userId并存入内存或 Redis 的user:1001:session_ids列表 -
设备层：每个 WebSocket 连接生成唯一
deviceId（如 UUID 或前端传入的 fingerprint），用于区分同用户的多终端，避免重复推送 -
房间层：业务决定粒度，比如文档协同用
room:doc_abc123，聊天室用room:group_789；服务端只向该房间内、且属于目标用户的活跃连接推送
注意：ServerEndpointExporter 在 SpringBoot 中默认不支持路径参数注入，需手动从 Session.getUserProperties() 取 userId，否则 @PathParam 会失效。
消息格式里必须带 type 和 target 字段
客户端收到裸 JSON 不知道怎么处理，服务端也难做路由判断。一个最小可用的消息结构应包含：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
{ "type": "UPDATE", "target": "room:doc_xxx", "data": { "id": "item_1", "content": "hello" }, "timestamp": 1748148360000 }
其中 type 决定前端走哪个 reducer，target 决定服务端往哪个房间/用户/设备发。漏掉 target 就等于放弃路由能力，所有消息只能走全量广播——这是压垮集群的第一步。
分布式环境下 session 映射必须外置
若依微服务或 SpringCloud 架构下，WebSocket 服务常被负载到多个实例。此时 ConcurrentHashMap<string session></string> 只在单机有效，跨节点无法感知连接状态。必须用外部存储做会话映射：
- Redis Hash 存
user:1001 → { sessionId1: deviceA, sessionId2: deviceB } - Redis Set 存
room:doc_xxx → [sessionId1, sessionId3] - 每次推送前先查 Redis 获取目标 session ID 列表，再遍历调用
session.getBasicRemote().sendText()
容易被忽略的是：Redis 读取失败时不能静默跳过，必须降级为本地内存兜底并打告警日志——否则用户会发现“有时候能同步，有时候不能”，排查成本极高。
