Spring WebSocket：如何通过AbstractSubProtocolEvent体系拦截Send事件？

这个问题问得挺精准的，刚好说到了Spring WebSocket事件模型的设计思路～

为什么没有对应Send操作的AbstractSubProtocolEvent子类？ #

Spring之所以没给客户端Send操作（比如你代码里的stompClient.send('/app/ws/something', {}, JSON.stringify({'content': $('#content').val()}))）提供对应的AbstractSubProtocolEvent子类，核心是事件定位和性能考量：

• 事件的定位差异：AbstractSubProtocolEvent下的现有子类（比如SessionConnectEvent、SessionConnectedEvent）都是用来标识WebSocket会话生命周期的关键节点——这些是低频、高价值的状态变化，比如客户端首次发起连接、会话正式建立、订阅/取消订阅频道等，Spring发布这些事件是为了让开发者感知会话的整体状态流转。而Send操作是高频的业务消息投递，属于消息流层面的常规操作，并不属于会话状态变更的范畴。
• 性能开销的考量：如果给每个Send消息都触发一个ApplicationEvent，会带来不必要的性能损耗。因为事件发布和监听默认是同步执行的，大量高频消息会拖慢整个消息处理链路，这显然不符合高性能消息处理的需求。
• 职责边界的清晰划分：Spring有意把“会话生命周期监听”和“消息流拦截处理”做了明确区分——ApplicationEvent体系专注于会话级别的状态通知，而消息的拦截、修改、校验等操作，交给ChannelInterceptor体系来处理，这样职责更清晰，也更灵活。

是不是必须通过ChannelInterceptor处理Send事件？ #

不是“必须”，但ChannelInterceptor是处理全局Send事件最适合的方案，具体分两种场景：

1. 全局拦截所有Send消息：如果需要对所有客户端发送的Stomp消息（不管有没有对应的@MessageMapping处理器）做统一处理（比如日志记录、权限校验、消息内容脱敏），那ChannelInterceptor是最优选择。注意现在ChannelInterceptorAdapter已经被标记为过时了，推荐直接实现ChannelInterceptor接口，重写preSend（发送前处理）或postSend（发送后处理）方法，示例代码如下：

@Component
public class StompSendGlobalInterceptor implements ChannelInterceptor {
    @Override
    public Message<?> preSend(Message<?> message, MessageChannel channel) {
        StompHeaderAccessor accessor = MessageHeaderAccessor.getAccessor(message, StompHeaderAccessor.class);
        // 判断是否为SEND命令
        if (accessor != null && StompCommand.SEND.equals(accessor.getCommand())) {
            // 这里可以处理Send事件的逻辑，比如获取目的地、消息内容
            String destination = accessor.getDestination();
            Object payload = message.getPayload();
            System.out.println("Received client Send message to: " + destination + ", content: " + payload);
            // 也可以修改消息内容或头信息
        }
        return message;
    }
}

2. 针对特定@MessageMapping的消息处理：如果只是想处理某个或某几个@MessageMapping对应的Send消息，可以在@MessageMapping方法里直接处理，或者用@ControllerAdvice配合@MessageExceptionHandler做全局异常处理，但这种方式只能覆盖有映射的消息，无法处理所有Send请求。

总结一下：Spring没有为Send操作提供ApplicationEvent，是因为它不属于会话生命周期的关键事件，而是高频业务消息；处理Send事件最通用的方式是用ChannelInterceptor，当然也可以根据具体场景选择其他方案。

内容的提问来源于stack exchange，提问作者Manuel Jordan