@Aspect无法拦截WebSocketHandler方法，因其通常由WebSocketConfigurer手动new创建，未被Spring容器管理，AOP代理失效；正确做法是使用HandshakeInterceptor透传上下文，并在handler中显式调用日志/异常上报工具。
不能直接用 @Around 拦截 WebSocketHandler 的 handleTextMessage 等方法 —— Spring AOP 默认不代理非 Spring Bean 管理的对象，而 WebSocketHandler 实例通常由 WebSocketConfigurer 手动 new 出来，不在 IoC 容器中。
为什么 @Aspect 对 WebSocketHandler 方法无效
Spring AOP 是基于代理（JDK 动态代理或 CGLIB）实现的，只对被 Spring 容器管理的 Bean 生效。当你在 WebSocketConfig 中写 new ExceptionWebSocketHandler()，这个对象就游离在 Spring 生命周期之外，@Aspect 根本看不到它。
- 常见错误现象：
@Pointcut("execution(* com.example.ExceptionWebSocketHandler.*(..))")完全不触发，日志无输出 - 即使把
ExceptionWebSocketHandler改成@Component，也需确保它被registry.addHandler()注册的是同一个 Spring 管理的 Bean 实例（否则仍会 new 一个新实例） - 更隐蔽的问题：Spring WebSocket 内部使用
WebSocketSession和异步回调，部分方法（如afterConnectionClosed）可能在非主线程执行，AOP 切面若依赖RequestContextHolder或 ThreadLocal 会取不到上下文
正确做法：用 HandlerInterceptor + WebSocketSession 属性透传
把 WebSocket 连接生命周期“拉回” Spring Web 的可控链路里，核心是利用 HandshakeInterceptor 在握手阶段注入标识，并通过 WebSocketSession.getAttributes() 传递上下文。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 在
WebSocketConfig中注册自定义拦截器：registry.addHandler(new ExceptionWebSocketHandler(), "/exception-monitor").addInterceptors(new LoggingHandshakeInterceptor()) -
LoggingHandshakeInterceptor实现HandshakeInterceptor，在beforeHandshake中存入用户 ID、IP、请求路径等：attributes.put("clientIp", getClientIpAddress(request)) -
ExceptionWebSocketHandler中通过session.getAttributes().get("clientIp")取值，避免重复解析 - 所有消息处理逻辑（
handleTextMessage）内手动调用日志工具类，例如：WebSocketLogUtils.recordReceive(session, message.getPayload())
异常监控必须绕过 try-catch 黑盒
WebSocket 处理器中的异常默认会被 Spring WebSocket 底层吞掉，只打印 warn 日志，不会进入 @RestControllerAdvice 或 AOP 的 @AfterThrowing。
- 必须显式捕获并重抛为 Spring 可识别的异常类型，例如：
throw new RuntimeException("WS message parse failed", e) - 在
ExceptionWebSocketHandler的handleTransportError中主动上报异常：WebSocketExceptionReporter.report(session, exception) - 若需实时推送异常给前端，不要在切面里发 WebSocket 消息 —— 此时 session 可能已关闭；应改用
SimpMessagingTemplate向 topic 推送，由前端订阅/topic/exceptions - 注意
handleTransportError和afterConnectionClosed的参数CloseStatus包含真实错误码，比如CloseStatus.SERVICE_RESTART表示服务端主动断连，不应记为客户端异常
性能与线程安全的关键细节
WebSocket 是长连接高并发场景，日志和异常处理不能成为瓶颈。
- 避免在
handleTextMessage中做 JSON 序列化或 DB 写入 —— 改用异步队列（如ThreadPoolTaskExecutor提交Runnable） -
CopyOnWriteArraySet<websocketsession></websocketsession>虽线程安全，但遍历开销大；高频广播场景建议换用ConcurrentHashMap<string websocketsession></string>，以 session.getId() 为 key - 日志字段如请求参数、返回内容要限制长度（例如截断前 512 字符），防止 OOM 或磁盘打满
- 别在切面里调用
session.sendMessage()—— 若 session 已失效，会抛出IllegalStateException，形成二次异常
真正难的不是写 AOP 注解，而是搞清 WebSocket 的生命周期和 Spring 容器边界的交界处。那里没有自动代理，也没有统一异常处理器，所有透传、兜底、异步都要自己补全。
