不能只靠@serverendpoint做商户通知，因其在集群部署时连接状态无法共享、缺乏心跳保活与自动重连机制、session失效导致推送失败；须用stomp+spring boot消息代理实现主题订阅、可靠重连与线程安全推送。
WebSocket 实现订单自动提醒，关键不在“连得上”，而在“推得准、断不丢、重连稳”。直接用 @ServerEndpoint 写个裸连接容易，但生产环境里商家刷新页面、网络抖动、部署扩容后连接失联——这些才是真问题。
为什么不能只靠 @ServerEndpoint 做商户通知？
裸 WebSocket 服务（如 @ServerEndpoint("/ws/{sid}")）在单机开发时能跑通，但一上生产就暴露三个硬伤：
- 连接状态全靠静态 Map 管理（如
static Map<string session></string>），集群部署时其他节点根本看不到这个商家连在哪台机器上 - 没有心跳保活或自动重连逻辑，Wi-Fi 切换、手机锁屏、Nginx 超时（默认 60s）都会静默断连，且前端收不到明确错误
- 推送消息只能靠
session.getBasicRemote().sendText()，但Session对象可能已失效，调用会抛IllegalStateException或静默失败
必须用 STOMP + Spring Boot Message Broker
Spring Boot 的 @EnableWebSocketMessageBroker 不是锦上添花，而是解决路由、广播、订阅隔离的刚需。它把“推给哪个商家”这件事从代码里抽出来，交给协议层处理：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 商家登录后，前端用唯一
shop_id订阅专属主题，例如/topic/shop_123；后端发消息只往这个路径写，Broker 自动投递给所有订阅该主题的客户端 - 连接断开时，STOMP 客户端（如
stompjs）可配置reconnectDelay和maxReconnectAttempts，比手写onclose → setTimeout → new WebSocket()更可靠 - 服务端推送用
simpMessagingTemplate.convertAndSend("/topic/shop_123", order)，完全不碰Session，规避了对象失效风险
订单触发推送时，别在 Controller 里直接 emit
订单创建通常发生在 HTTP 请求中（如 @PostMapping("/orders")），但此时不能直接调用 WebSocket 推送逻辑——因为 Spring 的 WebSocket 上下文和 HTTP 上下文是分离的：
- 若在 Controller 方法里硬写
webSocketServer.sendMessage("shop_123", order)，就得把WebSocketServer设为@Component并注入，但它的静态sessionMap在集群下无效 - 更糟的是，如果订单创建走异步（如
@Async）或 MQ 消费（如 RabbitMQ），HTTP 请求上下文早已销毁，current_app或ApplicationContext都拿不到 - 正确做法：用
SimpMessagingTemplate（线程安全）或发消息到 Redis 队列，由独立消费者统一处理推送——这样无论订单来自 API、MQ 还是定时任务，推送入口都一致
浏览器语音提醒必须绑定用户手势
想让新订单来时自动“叮咚”一声？Audio.play() 在 Chrome/Firefox 中受策略限制，非用户主动触发（如 click、keydown）时会被静音：
- 不能在
stompClient.onMessage回调里直接new Audio().play()，99% 情况下会失败并报DOMException: play() failed because the user didn't interact with the document first - 可行方案：首次登录/进入后台时，引导用户点一次“开启声音”按钮，用那次点击建立音频上下文；之后所有语音提示都复用这个已激活的
AudioContext - 备用方案：改用 Web Notifications API（
Notification.requestPermission()+new Notification()），它不依赖用户手势，但需额外申请权限
真正难的不是第一次连上 WebSocket，而是让第 5000 个商家在凌晨三点网络波动时，依然能收到那条“您有新订单”的语音提醒——这要求你把重连逻辑写进前端 SDK，把房间路由交给 STOMP Broker，把推送入口收束到统一的消息总线，而不是散落在十几个 Controller 里。
