WebSocket核心是建立持久双向通信通道，由后端业务逻辑（如事件触发、定时任务）决定推送时机；需管理连接、保活及安全防护。
WebSocket 实现消息推送的核心是建立一条持久、双向的通信通道，让服务端能主动把新消息实时发给客户端，而不是等客户端一次次来问。它不是“自动定时推送”的工具，而是一条随时可用的“高速路”，真正决定“什么时候发、发什么”的，是后端业务逻辑（比如定时任务、事件触发、数据库变更监听等）。
建立连接：先打通前后端这条“线”
前端用 new WebSocket(url) 发起连接，URL 是 ws:// 或 wss:// 开头；后端需提供对应端点（如 Spring Boot 的 @ServerEndpoint("/msg") 或 Gorilla 的 upgrader.Upgrade()）。连接过程本质是 HTTP 升级：客户端带 Upgrade: websocket 头发起请求，服务端返回 101 Switching Protocols 完成握手。成功后，连接保持打开，不关闭。
管理连接：让服务端知道“谁在线”
服务端必须保存每个活跃连接的引用（比如 Session、Conn 或自定义 Client 对象），否则无法定向或广播推送。常见做法有：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 用线程安全集合（如 Java 的
CopyOnWriteArraySet<session></session>或 Go 的map[*Client]bool+ 读写锁）存所有连接 - 使用 Hub 模式：单独一个 goroutine 或线程监听注册/注销/消息广播 channel，统一调度
- 避免直接在 onMessage 回调里遍历全部连接发消息，容易阻塞主逻辑
触发推送：消息从哪来、什么时候发
WebSocket 本身不产生消息，只负责传输。实际推送时机由业务驱动：
- 用户操作触发：比如点赞后，后端处理完数据库，立刻通过已保存的连接向该用户或相关房间推送通知
- 定时任务触发：用 Spring 的
@Scheduled、Go 的time.Ticker或 Quartz 等，每隔 N 秒查一次数据库或缓存，有新数据就广播 - 事件监听触发：监听 MQ 消息、Redis Pub/Sub、数据库 binlog 等，一收到变更就推送给前端
稳定运行：别让连接悄悄断掉
长连接可能因网络抖动、NAT 超时、代理中断而断开，需主动保活：
- 服务端定期发
Ping帧，客户端收到自动回Pong；客户端也可反向 Ping - 设置合理的读写超时（如 Go 中
SetReadDeadline），超时未收到心跳则主动 close 连接 - 前端监听
onclose事件，断连后可自动重连（带退避策略，如 1s、2s、4s…） - 生产环境注意 Origin 校验、连接数限制、消息大小控制，防止被滥用
