WebSocket广播通知的核心是服务端维护连接池并遍历活跃连接发送消息，客户端监听onmessage实时接收；需检查readyState、分组存储、心跳清理、JSON传输及业务触发广播。
WebSocket 实现服务器主动广播通知，核心在于服务端维护连接池、统一管理客户端，并在需要时遍历所有活跃连接发送消息。浏览器端只需监听消息事件即可实时接收，无需轮询或额外请求。
服务端：建立连接池并广播消息
以 Node.js + ws 库为例，服务端启动后会为每个新连接创建 WebSocket 实例，并存入一个数组或 Map 中。广播时遍历该集合，向每个“还活着”的连接调用 send() 方法。
- 使用
Set或Map存储连接，避免重复和便于清理（如断开时删除） - 发送前检查
readyState === WebSocket.OPEN，跳过已关闭或正在关闭的连接 - 若需区分用户或房间，可按标签（如 roomID、userID）分组存储连接，再对指定组广播
客户端：监听 onmessage 并处理通知
前端通过 new WebSocket(url) 建立连接后，直接监听 onmessage 事件。服务器广播来的任何消息都会触发该回调，前端解析内容并更新 UI。
- 建议用 JSON 格式传输，方便携带类型、时间、内容等字段（如
{type: "notice", data: {...}}） - 添加错误和关闭重连逻辑，避免连接中断后收不到后续通知
- 避免在
onmessage中执行耗时操作，必要时用requestIdleCallback或 Web Worker 卸载压力
广播时机与业务控制
广播不是无条件群发，而是由具体业务触发。例如订单状态变更、系统公告发布、聊天室新消息等，服务端在对应逻辑中调用广播函数。
立即学习“Java免费学习笔记（深入）”；
- 可在数据库写入成功后立即广播，也可结合消息队列（如 Redis Pub/Sub）解耦广播逻辑
- 敏感操作（如用户踢出、权限变更）建议带上签名或校验，防止伪造广播
- 高频广播场景（如实时行情）要考虑限流或合并消息，避免压垮客户端
注意连接生命周期与资源清理
WebSocket 是长连接，服务端必须及时响应 close 和 error 事件，从连接池中移除失效实例，否则内存泄漏风险高。
- 监听
socket.on('close', ...)和socket.on('error', ...)，执行清理 - 设置心跳机制（如每 30 秒 ping/pong），识别并剔除假死连接
- Node.js 中可配合
server.clients（ws 提供）快速获取当前所有连接
