不能直接用 session ID 或 URL 路径参数关闭 WebSocket 连接，因为 WebSocketSession 是一次性对象，由容器（如 Tomcat）管理生命周期，session.getId() 仅为无引用的字符串标识，连接断开、超时或异常后该 ID 对应实例可能已失效；URL 路径仅在握手阶段可用，后续消息中不携带，无法用于运行时查找。

服务端不能靠 URL 路径或 session ID 直接关连接，必须自己维护用户标识（如 userId）与 WebSocketSession 的映射关系，并在关闭前校验会话有效性。

为什么不能直接用 session ID 或路径参数？

WebSocketSession 是一次性对象，容器（如 Tomcat）管理其生命周期。session.getId() 只是字符串标识，不带引用；连接断开、超时或异常后，该 ID 对应的 session 实例可能已失效或被回收。URL 路径（如 /websocket/{userId}）只在握手阶段可用，后续消息中不携带，无法用于运行时查找。

如何安全绑定和查找用户会话

核心是在连接建立时完成业务标识与 session 的双向绑定：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 在 @OnOpen 方法中，从握手请求头（如 Authorization、X-User-ID）或 URI 查询参数提取 userId，校验通过后再存入线程安全容器（推荐 ConcurrentHashMap<String, WebSocketSession>）
• 键用 userId，值存 session 实例；避免用 session.getId() 作 key，因其不具备业务语义且不可靠
• 在 @OnClose 和 @OnError 回调中，务必从 map 中移除对应项，防止内存泄漏和误关已失效连接

如何主动关闭指定用户的连接

找到 session 后，需先判断状态再执行 close：

• 从 map 中获取目标 userId 对应的 session
• 检查 session != null && session.isOpen()，跳过已关闭或 null 的实例
• 调用 session.close(CloseStatus.POLICY_VIOLATION.withReason("logged_in_elsewhere")) 或自定义码（如 4000）
• 关闭前可选发送踢人消息：session.sendMessage(new TextMessage("{\"type\":\"kicked\"}"))，通知前端处理
• close() 执行后立即从 map 中 remove 该 userId，确保下次登录能正确覆盖

常见异常与规避要点

直接 close() 可能抛出 IllegalStateException 或 I/O 错误，主要因 session 已关闭、被回收或处于 CLOSING 状态：

• 所有 close() 调用必须包裹空值和 isOpen() 判断
• 不要在 @OnClose 回调里重复 close()，避免递归触发
• 避免在异步任务（如定时器、消息队列）中持有 session 引用过久，应尽快查 map、判状态、关连接、清引用
• 关闭码严格按 RFC 6455：推荐用 1000（正常）、4000–4999（业务自定义），禁用负数、超范围值或字符串