websocket实现股票行情推送的核心是建立长连接后稳定接收、正确解析并及时更新界面。需前端处理重连与订阅、服务端按需广播、前端防抖渲染、容错降级，确保数据实时性与用户体验。
用 WebSocket 实现股票行情实时推送，核心是建立浏览器与服务端的长连接，让服务端主动把最新价格、涨跌幅、成交量等数据推送给前端，避免轮询开销。关键不在“怎么连”，而在于“连上后怎么稳定收、正确解析、及时更新界面”。
一、前端建立 WebSocket 连接并监听行情数据
前端需指定支持 WebSocket 的行情服务地址（如 wss://api.example.com/stock），连接成功后监听 message 事件。注意处理重连逻辑，因为网络波动或服务重启会导致断连。
- 使用
new WebSocket(url)创建连接，推荐用wss://（加密）保障数据安全 - 在
onopen中发送订阅请求，例如 JSON 字符串：{"type":"subscribe","symbols":["600519.SH","000001.SZ"]} - 在
onmessage中解析返回的行情数据（通常是 JSON 格式），提取symbol、lastPrice、changePercent等字段 - 用
onerror和onclose触发自动重连（建议带退避策略，如 1s → 2s → 4s）
二、服务端需支持订阅/广播模型
股票行情不是全量广播，而是按用户订阅的代码精准推送。服务端（如 Node.js + ws 库）要维护「连接 → 订阅列表」映射关系。
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 收到客户端
subscribe消息后，将该连接加入对应股票代码的订阅池（可用 Map 或 Redis Set） - 当行情引擎（对接交易所 Level2 或第三方数据源）收到新 tick 数据时，只向订阅了该代码的所有连接推送，不群发
- 推送消息结构建议统一，例如：
{"symbol":"600519.SH","price":1892.5,"time":1717023456123,"volume":24800} - 定期发送心跳（ping/pong）防止代理或 NAT 超时断连
三、前端渲染要防抖+局部更新，避免卡顿
高频行情（如沪深 A 股主力合约可达每秒数十条）直接频繁操作 DOM 会明显卡顿。必须做节流和差异化更新。
- 用
requestIdleCallback或setTimeout(..., 0)把渲染任务放到空闲帧，避免阻塞主线程 - 维护本地行情缓存对象（如
const cache = new Map()），只在lastPrice或changePercent真正变化时才更新对应 DOM 元素 - 对价格数字做格式化（保留两位小数）、涨跌加色（绿色↑ / 红色↓）、千分位分隔，提升可读性
- 避免用
innerHTML += ...全量重绘列表，改用document.getElementById('600519').querySelector('.price').textContent = '1892.50'
四、必须考虑容错与降级方案
真实场景中 WebSocket 不可能 100% 可靠。不能让用户看到“连接中断”就停止刷新，要有兜底机制。
- 连接失败时，先尝试本地缓存数据继续显示（标注“数据延迟”提示），同时后台静默重连
- 若连续重连失败超过 3 次，自动降级为 5 秒 HTTP 轮询（
fetch('/api/ticks?symbols=...')），直到 WebSocket 恢复 - 服务端推送的数据必须带时间戳（毫秒级），前端校验是否严重滞后（如 > 3 秒），丢弃过期数据，防止界面显示“倒流行情”
- 敏感操作（如交易下单）绝不依赖 WebSocket 数据，应以订单确认接口返回为准
不复杂但容易忽略：WebSocket 是双工通道，但行情场景基本是服务端单向推；真正难点在连接管理、数据一致性、前端性能和用户体验的平衡。从连上、订上、收到、看清，每一步都要有明确状态反馈和异常兜底。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
