WebSocket实现股票行情推送需确保wss://协议、幂等订阅、二进制帧解析（设binaryType='arraybuffer'）及DOM更新节流（requestAnimationFrame+阈值过滤）。
WebSocket 是网页端实现实时股票行情推送最直接、高效的方式，它用单个长连接替代反复轮询，让价格、涨跌幅、成交量等数据毫秒级抵达前端——但真正落地时，“连得上”只是起点，“连得稳、推得准、收得全”才是盯盘体验的关键。
必须用 wss://，否则 HTTPS 页面会静默失败
现代浏览器强制要求：HTTPS 页面中调用 new WebSocket() 时，URL 必须以 wss:// 开头。用 ws:// 不会抛错，也不会打印日志，只在控制台显示模糊提示：“Connection closed before receiving a handshake response”。
- 后端若只监听
ws://（如本地调试用ws://localhost:8080），上线前必须通过 Nginx 等反向代理透传wss://流量，并配置有效 TLS 证书 - 前端连接代码别硬编码协议，可动态判断：
const protocol = location.protocol === 'https:' ? 'wss:' : 'ws:'; - 测试阶段可用
localhost绕过证书限制，但正式环境必须走真实wss://，否则 iOS Safari 和新版 Chrome 会彻底拒绝连接
订阅要幂等，重连别重复发
很多前端把 onopen 当作“已就绪”，立刻发 {"type":"subscribe","symbols":["SH600519"]}，但此时服务端连接对象可能尚未完成鉴权或注册订阅组；更糟的是，重连逻辑没去重，导致多次 onopen 触发相同订阅，引发漏推或重复推。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 建议服务端收到连接后先回一个
{"type":"ready"}，前端收到后再发订阅 - 所有订阅请求带上唯一
req_id字段，服务端对同一client_id + symbol的重复subscribe做幂等处理（只加入一次） -
unsubscribe同样需走完整流程，避免断线重连后旧订阅残留，造成冗余推送和内存泄漏
二进制帧要设 binaryType，否则解析为空
真实行情系统普遍采用二进制协议（如 Protocol Buffer 或自定义紧凑帧），体积比 JSON 小 60%+，解析快 3–5 倍。但浏览器默认把 WebSocket 消息当文本处理，若服务端发的是 ArrayBuffer，前端没显式设置 binaryType，e.data 会是 null 或乱码字符串。
- 创建连接后立即设置：
socket.binaryType = 'arraybuffer'; - 解析时用
new Uint8Array(e.data)或new DataView(e.data)读原始字节，别尝试TextDecoder解码 - 若服务端同时支持 JSON 和二进制，可通过 URL 参数区分，如
wss://api.example.com?format=bin
更新 DOM 要节流，高频渲染会卡顿
逐笔成交每秒几十条，若每次 onmessage 都直接操作 document.getElementById('price-600519').innerText = data.price，会触发大量 layout thrashing 和强制同步重排，CPU 占用飙升。
- 用
Map缓存股票代码到 DOM 元素的映射，避免重复查找 - 只在内存中更新最新值，不碰 DOM；用
requestAnimationFrame批量合并刷新（例如收集 16ms 内所有 tick 后统一更新） - 价格变动小于阈值（如 0.01 元）时跳过 DOM 更新，仅维护内存状态
