Spring Boot 需自行维护 userId 与 WebSocketSession 的映射关系，并在关闭前校验 session.isOpen()；直接通过 session ID 或 URL 参数查找不可靠，因 session 为一次性对象且路径参数仅握手阶段可用。
Spring Boot 本身不提供“按用户 ID 动态关闭 WebSocket 连接”的开箱即用 API，必须自己维护 WebSocketSession 映射关系，并在需要时调用 session.close()。直接调用 session.close() 是唯一可靠方式，但前提是 session 未过期、未被容器回收、且未处于正在关闭状态。
为什么不能靠 session ID 或 URL 参数直接关连接
WebSocket 连接生命周期由容器（如 Tomcat）管理，WebSocketSession 是一次性的、不可复用的对象。即使你存了 session.getId()，它只是字符串标识，不带引用；如果 session 已因超时、异常或客户端静默断开而失效，再拿这个 ID 去查 map，得到的 session 很可能已调用过 close() 或抛出 IllegalStateException。
-
session.getId()无法反向获取活跃 session 实例，必须你自己在@OnOpen时主动存入线程安全容器（如ConcurrentHashMap） - 不要依赖 URL 路径参数（如
/websocket/{userId}）做运行时查找——路径只在握手阶段可用，后续消息中不自动携带 - 若使用
@ServerEndpoint注解方式，session.getUri().getQuery()或session.getRequestParameterMap()在某些容器下可能为空，不可靠
如何安全地存储和查找指定用户的 session
核心是：在连接建立时，把 WebSocketSession 和业务标识（如 userId）双向绑定；关闭时先校验 session 状态，再执行 close。
- 推荐用
ConcurrentHashMap<string websocketsession></string>存userId → session，避免并发 put/remove 冲突 - 务必在
@OnOpen方法中解析并校验业务参数（如从 URI 或 handshake request headers 中提取userId），失败则立即session.close(CloseStatus.NOT_ACCEPTABLE) - 在
@OnClose和@OnError中及时从 map 移除该 session，防止内存泄漏 - 关闭前加判空和状态检查：
if (session != null && session.isOpen()) { session.close(); }
动态关闭时容易触发的异常及应对
直接调用 session.close() 可能抛出以下异常，不处理会导致线程中断或日志刷屏：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
IOException：底层 socket 写失败（如客户端已断网），应捕获并记录，不影响逻辑 -
IllegalStateException：session 已关闭或无效，常见于重复关闭或 session 超时后仍尝试操作，需提前用session.isOpen()检查 -
NullPointerException：map 查不到对应 session，说明用户已离线或未成功握手，属于正常情况，无需报错
示例代码片段：
public void kickUser(String userId) {
WebSocketSession session = userSessionMap.get(userId);
if (session != null && session.isOpen()) {
try {
session.close(CloseStatus.GOING_AWAY.withReason("管理员强制下线"));
} catch (IOException e) {
log.warn("关闭用户 {} 的 WebSocket 连接失败: {}", userId, e.getMessage());
}
}
}
注意：CloseStatus 的选择影响前端行为
前端 WebSocket.onclose 会收到 event.code 和 event.reason，不同码值触发不同重连策略。例如：
- 用
CloseStatus.NORMAL（码 1000）：前端通常认为是“正常退出”，可能不自动重连 - 用
CloseStatus.GOING_AWAY（码 1001）：语义更贴近“服务端主动断开”，适合强制下线场景 - 避免用 4xxx 自定义码：部分浏览器或代理会截断或忽略非标准码，建议优先用 RFC 6455 定义的 1000–1015 范围
真正难的不是写那行 session.close()，而是保证 map 里存的是**当前有效、未过期、未被容器清理**的 session 引用——这要求你在握手、心跳、异常、超时、关闭全流程都做状态同步，漏掉任一环节，kickUser 就会静默失效。
