websocket本身不支持多级分组，必须自行实现树形分组逻辑；单层concurrenthashmap仅支持扁平标签（如“房间名”），无法表达“北京-研发部-ai组”等嵌套路径，且存在键设计难、查询慢（o(n)遍历）、状态不同步（多对多归属）等问题。
WebSocket 本身不支持多级分组，必须自己实现分组逻辑；直接用 session.getBasicRemote().sendText() 群发是平铺式广播，无法区分“群组A里的用户B”或“部门X下的子团队Y”这种嵌套关系。
为什么不能只靠 @ServerEndpoint + ConcurrentHashMap 做多级分组
常见写法是把所有在线 Session 存进一个 ConcurrentHashMap<string session></string>，再按用户名查、遍历发——这只能支撑单层标签（比如“房间名”），但无法表达“北京-研发部-AI组”这样的路径结构。一旦需要动态加入/退出某一层（如用户从“AI组”调岗到“测试组”，但仍在“研发部”），硬编码的 Map 键就容易冲突或漏删。
- 键设计难：用
"beijing-dev-ai"这种字符串拼接，增删层级要重算全路径，易出错 - 查询慢：找“所有北京地区的用户”，得遍历整个 Map 做
key.startsWith("beijing-")，O(n) 不可扩展 - 状态不同步：用户可能同时属于多个组（如“AI组”+“值班组”），单 Map 无法表达多对多
用嵌套的 ConcurrentMap + 路径树管理分组
核心思路是把分组建模成一棵树：每个节点是一个 ConcurrentMap，存下级节点或终端 Session。例如：
groups: {
"beijing": {
"dev": {
"ai": { "u123": session1, "u456": session2 },
"test": { "u789": session3 }
}
},
"shanghai": { ... }
}
这样支持任意深度查找和批量操作。实际代码中建议封装为 GroupTree 工具类，关键行为包括：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
joinGroup(String path, Session session)：按/beijing/dev/ai路径逐级创建节点，末级存 session -
leaveGroup(String path, String userId)：只删指定路径下的 session，不影响其他路径引用 -
broadcastToPath(String path, String msg)：递归遍历该路径下所有叶子 session 发送 - 避免用
String.split("/")频繁切分：缓存路径段数组，或用java.nio.file.Paths解析
分组消息如何避免重复发送和漏发
用户可能同时在多个路径下（如 /beijing/dev/ai 和 /oncall/team-a），此时发一条“系统通知”需广播到所有所属路径。但直接遍历所有路径再发，session 可能被重复写入多次，导致前端收到多条相同消息。
- 用
ConcurrentHashMap<session boolean></session>临时去重：先收集所有目标 session，再统一发 - 不要在
@OnMessage里实时计算路径：提前在@OnOpen时解析并注册到树中，减少每次消息的开销 - 注意
session.isOpen()检查：遍历时跳过已关闭的 session，否则会抛IllegalStateException - 异步发送更安全：
session.getAsyncRemote().sendText()不阻塞主线程，但需处理Throwable回调
WebFlux 场景下用 Sinks.Many 替代手动维护 session 集合
如果你用的是 Spring WebFlux（非传统 Servlet 容器），别硬套 ConcurrentHashMap<session string></session>。改用响应式流管理更自然：
- 每个分组对应一个
Sinks.Many<chatmessage></chatmessage>，用户连接时sink.asFlux().subscribe(...) - 发消息时调用
sink.tryEmitNext(msg)，自动推给所有订阅者 - 分组嵌套靠组合：例如
beijingSink订阅devSink和hrSink，天然形成树形广播 - 注意背压策略：
Sinks.many().multicast().onBackpressureBuffer()是常用配置，防止消息积压崩溃
真正复杂的地方不在“怎么发”，而在“谁该收到”——路径解析是否容错、用户移出分组时是否清理干净、跨服务部署时分组状态如何同步，这些才是压测和线上最容易翻车的点。
