1. 项目缘起与整体设计思路1.1 这个面板到底解决什么问题做量化交易或者股票行情监控的朋友大概率都遇到过这样的场景开盘期间需要同时盯十几只甚至几十只标的的实时价格跳动券商软件自带的行情列表要么刷新频率不够要么字段固定死板想加个自定义指标就得忍受卡顿。更麻烦的是很多轻量级的行情工具只给你一个静态快照价格变了不会主动推给你得手动刷新等你刷出来的时候短线机会早就过去了。tick-stock-panel这个项目从名字拆开看就很直白——tick 级别的股票面板。它的核心定位是一个轻量、可定制、支持实时推送的行情监控面板。所谓 tick 级别指的是它处理的是逐笔成交或盘口快照级别的高频数据而不是日线、分钟线那种粗粒度的行情。面板则意味着它最终呈现的是一个可视化的、多标的并列的监控界面。这个项目适合谁我梳理了三类人第一类是个人量化交易者手里跑着几个策略需要一个统一的行情看板来辅助人工盯盘或者做策略信号的二次确认第二类是金融数据方向的后端或全栈开发者想找一个结构清晰、可扩展的实时数据面板参考实现第三类是对实时数据可视化感兴趣的技术爱好者想通过一个具体项目理解 WebSocket 推送、前端高频渲染、数据节流这些工程问题。它解决的问题可以归纳为三点实时性数据主动推送而非轮询、可定制字段、布局、刷新策略都能改、轻量不依赖重型框架启动快资源占用低。这三点看起来简单但真正做起来每一个都有一堆坑要填。1.2 技术选型背后的取舍逻辑一个实时行情面板技术选型无非是前端渲染、数据传输、数据源接入这三块。我在设计这个项目的时候核心原则是够用就好不为了炫技引入复杂度。前端这块我没有选 React 或 Vue 这类框架而是用了原生 JavaScript 配合轻量级的 DOM 操作。原因很实际行情面板的 UI 结构其实非常固定就是一堆表格行每行几个字段价格变了改一下文本颜色和数值。这种场景下框架的虚拟 DOM diff 反而成了负担高频更新时 diff 的开销可能比直接改 DOM 还大。当然如果你的面板要支持复杂的交互比如拖拽排序、多标签页、图表联动那上框架是合理的但纯监控场景原生足够。数据传输用 WebSocket这是实时推送的标准方案。相比 HTTP 轮询WebSocket 的优势在于服务端可以主动推延迟低而且省去了反复建连的开销。这里有个细节很多行情源本身提供的就是 WebSocket 接口面板作为客户端直接对接即可如果行情源只提供 HTTP 接口那就需要在中间加一层服务端做转换把轮询拿到的数据通过 WebSocket 推给前端。数据源接入这块项目本身不绑定特定行情源而是定义了一套标准的数据格式任何能输出这个格式的数据源都能接进来。这样做的好处是解耦你可以接免费的公开行情接口也可以接付费的低延迟数据源面板层不用改。标准格式我后面会详细说核心就是包含标的代码、最新价、涨跌幅、成交量、时间戳这几个字段。提示技术选型没有绝对的对错关键是匹配场景。行情面板这种高频更新、结构固定、交互简单的场景轻量方案往往比重型框架更稳。1.3 整体架构分层项目整体分成三层我用一个表格把每层的职责和关键技术点列清楚层级职责关键技术点数据接入层对接行情源标准化数据格式WebSocket 客户端、HTTP 轮询兜底、数据清洗数据分发层接收数据并广播给前端WebSocket 服务端、连接管理、心跳保活展示层渲染面板处理用户交互原生 DOM、节流渲染、颜色映射数据接入层负责跟行情源打交道把不同格式的数据统一成标准格式。数据分发层是面板自己的服务端管理所有前端连接把数据广播出去。展示层就是浏览器里的面板负责把数据变成人眼能看的东西。这三层之间是松耦合的你可以只跑展示层对接现成的 WebSocket 服务也可以只跑数据接入层做数据采集。这种分层设计的好处是每一层都能独立测试和替换调试的时候定位问题也快——数据不对就查接入层推送断了就查分发层显示异常就查展示层。2. 核心细节解析与实操要点2.1 标准数据格式的设计数据格式是整个项目的契约定好了后面都好办定不好后面到处打补丁。我最终确定的标准格式是一个 JSON 对象字段如下{ symbol: 600519, name: 贵州茅台, price: 1688.50, prevClose: 1670.00, change: 18.50, changePercent: 1.11, volume: 1234567, amount: 2085000000, timestamp: 1700000000000 }这里有几个设计考量值得说。prevClose是必须的因为涨跌幅和涨跌额都要基于昨收计算如果只传最新价前端还得自己维护昨收容易出错。timestamp用毫秒级时间戳方便前端做延迟计算和数据新鲜度判断。change和changePercent虽然可以由前端算但我建议服务端算好一起传原因有两个一是减少前端计算量二是保证所有客户端看到的数值一致避免浮点计算差异。注意字段命名要统一风格。我见过有的项目里价格字段一会儿叫 price 一会儿叫 lastPrice这种不一致在多人协作时是灾难。定好一套命名规范写进文档谁都不能改。2.2 前端高频渲染的节流策略这是整个项目最容易踩坑的地方。行情数据可能每秒推送几十次甚至上百次如果每来一条就改一次 DOM浏览器很快就卡死了。我实测过不做任何优化的情况下50 个标的、每秒 100 次更新页面在十几秒内就会明显掉帧。解决方案是节流渲染。核心思路是数据来了先存到内存里不立即渲染而是用一个定时器每隔固定时间比如 200ms批量渲染一次。这样无论数据来得多快渲染频率都是可控的。const renderQueue new Map(); let renderTimer null; function onDataReceived(data) { renderQueue.set(data.symbol, data); if (!renderTimer) { renderTimer setTimeout(flushRender, 200); } } function flushRender() { renderTimer null; renderQueue.forEach((data, symbol) { updateRow(symbol, data); }); renderQueue.clear(); }这段代码的关键在于renderQueue用 Map 存储同一个标的的多次更新会被覆盖只保留最新的。这样即使某个标的在 200ms 内更新了 10 次最终也只渲染 1 次而且渲染的是最新值。200ms 这个间隔是权衡的结果人眼对 200ms 以内的变化基本感知不到延迟同时渲染频率降到每秒 5 次浏览器压力小很多。2.3 颜色映射与视觉反馈行情面板的视觉反馈直接影响盯盘效率。涨了显示红色、跌了显示绿色这是国内市场的习惯注意跟欧美市场相反。但光有颜色不够还要考虑变化方向和变化幅度。我的做法是价格相比上一次渲染上涨数字闪一下红色背景下跌闪绿色背景不变则保持默认。这个闪一下用 CSS 动画实现持续 300ms 后恢复。这样即使你眼睛没盯着某个标的余光也能捕捉到异动。keyframes flash-up { 0% { background-color: rgba(255, 0, 0, 0.3); } 100% { background-color: transparent; } } keyframes flash-down { 0% { background-color: rgba(0, 255, 0, 0.3); } 100% { background-color: transparent; } }涨跌幅的显示也要分级涨跌幅绝对值小于 1% 用普通字重1% 到 3% 加粗超过 3% 用更大的字号。这样一眼扫过去异动大的标的自然跳出来。2.4 WebSocket 连接管理与断线重连实时面板最怕的就是连接断了还不知道。WebSocket 断线的原因很多网络抖动、服务端重启、长时间无数据被中间设备断开。所以断线重连是必须的而且要做得聪明。我的重连策略是指数退避第一次断开后 1 秒重连失败则 2 秒再失败 4 秒最多退到 30 秒。这样既不会在服务端故障时疯狂重连打爆服务端又能在网络恢复后尽快连上。let reconnectDelay 1000; const MAX_DELAY 30000; function connect() { const ws new WebSocket(WS_URL); ws.onopen () { reconnectDelay 1000; updateStatus(connected); }; ws.onclose () { updateStatus(disconnected); setTimeout(connect, reconnectDelay); reconnectDelay Math.min(reconnectDelay * 2, MAX_DELAY); }; ws.onerror () ws.close(); }同时面板上要有一个明显的连接状态指示器。我用的是页面顶部一条细横条绿色表示连接正常黄色表示正在重连红色表示断开。这个细节很重要因为如果连接断了但界面还显示着旧数据你可能会基于过时信息做决策。提示除了断线重连还要做心跳保活。每隔 30 秒发一个 ping服务端回 pong超过一定时间没收到 pong 就主动断开重连。很多中间设备会清理长时间无数据的连接心跳能避免这种假连接。3. 实操过程与核心环节实现3.1 环境准备与项目初始化先把项目骨架搭起来。我用的目录结构如下tick-stock-panel/ ├── server/ │ ├── index.js # WebSocket 服务端入口 │ ├── dataSource.js # 行情源接入 │ └── broadcaster.js # 数据广播 ├── client/ │ ├── index.html │ ├── panel.js # 面板主逻辑 │ ├── render.js # 渲染模块 │ └── style.css └── package.json服务端用 Node.js依赖只有ws这一个库负责 WebSocket 服务端。前端零依赖纯原生。初始化命令mkdir tick-stock-panel cd tick-stock-panel npm init -y npm install ws这个极简的依赖是有意为之。依赖越少出问题的环节越少部署也越简单。整个项目跑起来只需要 Node.js 环境不需要构建工具不需要打包改完代码刷新页面就生效。3.2 服务端数据分发实现服务端的核心逻辑是接收行情源数据广播给所有连接的前端。先看广播模块const WebSocket require(ws); class Broadcaster { constructor(port) { this.wss new WebSocket.Server({ port }); this.clients new Set(); this.wss.on(connection, (ws) { this.clients.add(ws); ws.on(close, () this.clients.delete(ws)); ws.on(message, (msg) this.handleClientMessage(ws, msg)); }); } handleClientMessage(ws, msg) { const data JSON.parse(msg); if (data.type ping) { ws.send(JSON.stringify({ type: pong })); } } broadcast(payload) { const message JSON.stringify(payload); this.clients.forEach((ws) { if (ws.readyState WebSocket.OPEN) { ws.send(message); } }); } }这里有个性能细节broadcast里先JSON.stringify一次然后发给所有客户端而不是每个客户端单独序列化。在客户端数量多的时候这个优化能省不少 CPU。另外发送前检查readyState避免往已关闭的连接写数据导致报错。3.3 行情源接入与数据清洗行情源接入层要处理的核心问题是格式转换和异常过滤。不同行情源的字段名、数值单位、时间格式都不一样接入层要把它们统一成标准格式。function normalize(rawData) { const price parseFloat(rawData.last_price || rawData.price); const prevClose parseFloat(rawData.pre_close || rawData.prevClose); if (!isFinite(price) || !isFinite(prevClose) || prevClose 0) { return null; // 异常数据丢弃 } const change price - prevClose; const changePercent (change / prevClose) * 100; return { symbol: String(rawData.symbol || rawData.code), name: rawData.name || , price: round(price, 2), prevClose: round(prevClose, 2), change: round(change, 2), changePercent: round(changePercent, 2), volume: parseInt(rawData.volume, 10) || 0, amount: parseFloat(rawData.amount) || 0, timestamp: rawData.timestamp || Date.now() }; } function round(num, digits) { const factor Math.pow(10, digits); return Math.round(num * factor) / factor; }异常过滤这块我要重点说。行情数据里经常出现脏数据价格是 0、昨收是 0、价格突然变成负数、成交量是字符串。这些数据如果直接推到前端轻则显示异常重则导致计算错误。所以接入层必须做校验不合格的数据直接丢弃宁可少显示也不能显示错的。注意prevClose 0的判断很重要。有些行情源在集合竞价阶段会推送昨收为 0 的数据如果不过滤涨跌幅计算会变成 Infinity前端显示就乱了。3.4 前端面板渲染实现前端渲染分两部分初始化时创建表格结构数据更新时只改变化的单元格。初始化function initPanel(symbols) { const tbody document.querySelector(#panel tbody); tbody.innerHTML ; symbols.forEach((symbol) { const tr document.createElement(tr); tr.id row-${symbol}; tr.innerHTML td classcol-symbol${symbol}/td td classcol-name/td td classcol-price/td td classcol-change/td td classcol-percent/td td classcol-volume/td ; tbody.appendChild(tr); }); }更新时只改文本内容和 class不重建 DOMfunction updateRow(symbol, data) { const tr document.getElementById(row-${symbol}); if (!tr) return; const priceCell tr.querySelector(.col-price); const prevPrice parseFloat(priceCell.textContent) || data.price; priceCell.textContent data.price.toFixed(2); tr.querySelector(.col-name).textContent data.name; tr.querySelector(.col-change).textContent data.change.toFixed(2); tr.querySelector(.col-percent).textContent data.changePercent.toFixed(2) %; tr.querySelector(.col-volume).textContent formatVolume(data.volume); // 颜色和闪烁 const colorClass data.change 0 ? up : data.change 0 ? down : flat; tr.className colorClass; if (data.price prevPrice) { flash(priceCell, flash-up); } else if (data.price prevPrice) { flash(priceCell, flash-down); } }formatVolume把成交量转成万手亿手这种易读格式这个细节对盯盘体验提升很大毕竟没人愿意去数一长串数字。3.5 参数计算与性能调优实录渲染间隔定多少合适我做了几组实测数据如下渲染间隔CPU 占用视觉延迟适用场景50ms高几乎无感超短线标的少于 20 个100ms中无感一般短线标的 20-50 个200ms低轻微常规监控标的 50-100 个500ms很低可感知中长线标的 100最终我默认用 200ms同时把这个值做成可配置项。如果你的标的少、追求极致实时改成 100ms 甚至 50ms 都行如果标的特别多、机器性能一般调到 500ms 也能用。另一个性能点是表格行数。浏览器渲染几百行表格本身就有开销如果标的超过 200 个建议做虚拟滚动只渲染可视区域内的行。不过对于大多数个人用户监控 50 个以内的标的足够了虚拟滚动属于过度设计我没做。4. 常见问题与排查技巧实录4.1 连接类问题速查实时面板的问题里连接类占了一大半。我整理了一个速查表现象可能原因排查方法解决一直显示重连中服务端没启动或端口错检查服务端进程和端口启动服务端核对端口连上后几秒就断心跳没做或被中间设备清理看断开时间是否规律加心跳保活部分客户端连不上连接数超限看服务端连接数提高上限或加连接池数据延迟越来越大消息积压看服务端发送队列加节流或丢弃旧数据其中数据延迟越来越大这个坑我踩过。原因是服务端广播速度超过了客户端处理速度消息在客户端缓冲区堆积。解决办法是在客户端也做节流或者服务端检测到客户端处理不过来时主动丢弃中间数据只推最新值。行情场景下旧数据本来就没意义丢旧保新是合理的。4.2 数据类问题排查数据类问题最隐蔽因为界面看起来正常但数值可能是错的。常见的几种涨跌幅算错。八成是昨收取错了或者除权除息日没做复权处理。排查方法是拿几个标的的手算结果跟面板对比对不上就查昨收字段。成交量单位混乱。有的行情源给的是股有的是手差 100 倍。这个必须在接入层统一我建议统一用手因为国内习惯如此。时间戳时区问题。如果行情源给的是 UTC 时间前端显示时没转本地时区就会出现数据来自未来或数据来自过去的怪象。统一用毫秒时间戳显示时再转本地时间。提示接入新行情源时先拿 3 到 5 个标的的数据手工核对一遍确认价格、昨收、成交量、时间戳都对再接入全量。这个习惯能帮你省下大量排查时间。4.3 渲染类问题与避坑技巧渲染类问题主要表现为卡顿、闪烁、错位。卡顿前面说了节流能解决大部分。闪烁通常是频繁改 class 导致的解决办法是合并 DOM 操作一次改完。错位一般是表格列宽没固定数据长度变化时列宽跳动给每列设固定宽度或用table-layout: fixed就能解决。还有一个容易被忽略的问题数字跳动导致的视觉疲劳。价格每秒变好几次如果每次都闪眼睛很快就累了。我的做法是只对超过一定幅度比如 0.1%的变化才闪烁微小波动只改数字不闪。这个阈值可以配置找到自己舒服的值。4.4 部署与长期运行的注意事项面板如果要 7x24 小时运行有几个点要注意。服务端要加进程守护崩了能自动拉起。日志要定期清理不然磁盘会被写满。内存要监控长时间运行如果有内存泄漏几天后就会 OOM。我自己的部署方式是服务端跑在一台常开的小主机上前端用浏览器全屏打开。浏览器标签页长时间运行也可能内存增长建议每天刷新一次页面或者用定时任务自动刷新。这些都是实际跑久了才会遇到的问题提前做好能省不少心。最后分享一个我个人的小习惯面板上除了行情数据我还会加一个数据最后更新时间的显示。如果这个时间超过 5 秒没变说明数据流可能断了即使连接状态显示正常也要警惕。这个小小的字段帮我发现过好几次隐蔽的数据中断问题。
1. 项目缘起与整体设计思路1.1 这个面板到底解决什么问题做量化交易或者股票行情监控的朋友大概率都遇到过这样的场景开盘期间需要同时盯十几只甚至几十只标的的实时价格跳动券商软件自带的行情列表要么刷新频率不够要么字段固定死板想加个自定义指标就得忍受卡顿。更麻烦的是很多轻量级的行情工具只给你一个静态快照价格变了不会主动推给你得手动刷新等你刷出来的时候短线机会早就过去了。tick-stock-panel这个项目从名字拆开看就很直白——tick 级别的股票面板。它的核心定位是一个轻量、可定制、支持实时推送的行情监控面板。所谓 tick 级别指的是它处理的是逐笔成交或盘口快照级别的高频数据而不是日线、分钟线那种粗粒度的行情。面板则意味着它最终呈现的是一个可视化的、多标的并列的监控界面。这个项目适合谁我梳理了三类人第一类是个人量化交易者手里跑着几个策略需要一个统一的行情看板来辅助人工盯盘或者做策略信号的二次确认第二类是金融数据方向的后端或全栈开发者想找一个结构清晰、可扩展的实时数据面板参考实现第三类是对实时数据可视化感兴趣的技术爱好者想通过一个具体项目理解 WebSocket 推送、前端高频渲染、数据节流这些工程问题。它解决的问题可以归纳为三点实时性数据主动推送而非轮询、可定制字段、布局、刷新策略都能改、轻量不依赖重型框架启动快资源占用低。这三点看起来简单但真正做起来每一个都有一堆坑要填。1.2 技术选型背后的取舍逻辑一个实时行情面板技术选型无非是前端渲染、数据传输、数据源接入这三块。我在设计这个项目的时候核心原则是够用就好不为了炫技引入复杂度。前端这块我没有选 React 或 Vue 这类框架而是用了原生 JavaScript 配合轻量级的 DOM 操作。原因很实际行情面板的 UI 结构其实非常固定就是一堆表格行每行几个字段价格变了改一下文本颜色和数值。这种场景下框架的虚拟 DOM diff 反而成了负担高频更新时 diff 的开销可能比直接改 DOM 还大。当然如果你的面板要支持复杂的交互比如拖拽排序、多标签页、图表联动那上框架是合理的但纯监控场景原生足够。数据传输用 WebSocket这是实时推送的标准方案。相比 HTTP 轮询WebSocket 的优势在于服务端可以主动推延迟低而且省去了反复建连的开销。这里有个细节很多行情源本身提供的就是 WebSocket 接口面板作为客户端直接对接即可如果行情源只提供 HTTP 接口那就需要在中间加一层服务端做转换把轮询拿到的数据通过 WebSocket 推给前端。数据源接入这块项目本身不绑定特定行情源而是定义了一套标准的数据格式任何能输出这个格式的数据源都能接进来。这样做的好处是解耦你可以接免费的公开行情接口也可以接付费的低延迟数据源面板层不用改。标准格式我后面会详细说核心就是包含标的代码、最新价、涨跌幅、成交量、时间戳这几个字段。提示技术选型没有绝对的对错关键是匹配场景。行情面板这种高频更新、结构固定、交互简单的场景轻量方案往往比重型框架更稳。1.3 整体架构分层项目整体分成三层我用一个表格把每层的职责和关键技术点列清楚层级职责关键技术点数据接入层对接行情源标准化数据格式WebSocket 客户端、HTTP 轮询兜底、数据清洗数据分发层接收数据并广播给前端WebSocket 服务端、连接管理、心跳保活展示层渲染面板处理用户交互原生 DOM、节流渲染、颜色映射数据接入层负责跟行情源打交道把不同格式的数据统一成标准格式。数据分发层是面板自己的服务端管理所有前端连接把数据广播出去。展示层就是浏览器里的面板负责把数据变成人眼能看的东西。这三层之间是松耦合的你可以只跑展示层对接现成的 WebSocket 服务也可以只跑数据接入层做数据采集。这种分层设计的好处是每一层都能独立测试和替换调试的时候定位问题也快——数据不对就查接入层推送断了就查分发层显示异常就查展示层。2. 核心细节解析与实操要点2.1 标准数据格式的设计数据格式是整个项目的契约定好了后面都好办定不好后面到处打补丁。我最终确定的标准格式是一个 JSON 对象字段如下{ symbol: 600519, name: 贵州茅台, price: 1688.50, prevClose: 1670.00, change: 18.50, changePercent: 1.11, volume: 1234567, amount: 2085000000, timestamp: 1700000000000 }这里有几个设计考量值得说。prevClose是必须的因为涨跌幅和涨跌额都要基于昨收计算如果只传最新价前端还得自己维护昨收容易出错。timestamp用毫秒级时间戳方便前端做延迟计算和数据新鲜度判断。change和changePercent虽然可以由前端算但我建议服务端算好一起传原因有两个一是减少前端计算量二是保证所有客户端看到的数值一致避免浮点计算差异。注意字段命名要统一风格。我见过有的项目里价格字段一会儿叫 price 一会儿叫 lastPrice这种不一致在多人协作时是灾难。定好一套命名规范写进文档谁都不能改。2.2 前端高频渲染的节流策略这是整个项目最容易踩坑的地方。行情数据可能每秒推送几十次甚至上百次如果每来一条就改一次 DOM浏览器很快就卡死了。我实测过不做任何优化的情况下50 个标的、每秒 100 次更新页面在十几秒内就会明显掉帧。解决方案是节流渲染。核心思路是数据来了先存到内存里不立即渲染而是用一个定时器每隔固定时间比如 200ms批量渲染一次。这样无论数据来得多快渲染频率都是可控的。const renderQueue new Map(); let renderTimer null; function onDataReceived(data) { renderQueue.set(data.symbol, data); if (!renderTimer) { renderTimer setTimeout(flushRender, 200); } } function flushRender() { renderTimer null; renderQueue.forEach((data, symbol) { updateRow(symbol, data); }); renderQueue.clear(); }这段代码的关键在于renderQueue用 Map 存储同一个标的的多次更新会被覆盖只保留最新的。这样即使某个标的在 200ms 内更新了 10 次最终也只渲染 1 次而且渲染的是最新值。200ms 这个间隔是权衡的结果人眼对 200ms 以内的变化基本感知不到延迟同时渲染频率降到每秒 5 次浏览器压力小很多。2.3 颜色映射与视觉反馈行情面板的视觉反馈直接影响盯盘效率。涨了显示红色、跌了显示绿色这是国内市场的习惯注意跟欧美市场相反。但光有颜色不够还要考虑变化方向和变化幅度。我的做法是价格相比上一次渲染上涨数字闪一下红色背景下跌闪绿色背景不变则保持默认。这个闪一下用 CSS 动画实现持续 300ms 后恢复。这样即使你眼睛没盯着某个标的余光也能捕捉到异动。keyframes flash-up { 0% { background-color: rgba(255, 0, 0, 0.3); } 100% { background-color: transparent; } } keyframes flash-down { 0% { background-color: rgba(0, 255, 0, 0.3); } 100% { background-color: transparent; } }涨跌幅的显示也要分级涨跌幅绝对值小于 1% 用普通字重1% 到 3% 加粗超过 3% 用更大的字号。这样一眼扫过去异动大的标的自然跳出来。2.4 WebSocket 连接管理与断线重连实时面板最怕的就是连接断了还不知道。WebSocket 断线的原因很多网络抖动、服务端重启、长时间无数据被中间设备断开。所以断线重连是必须的而且要做得聪明。我的重连策略是指数退避第一次断开后 1 秒重连失败则 2 秒再失败 4 秒最多退到 30 秒。这样既不会在服务端故障时疯狂重连打爆服务端又能在网络恢复后尽快连上。let reconnectDelay 1000; const MAX_DELAY 30000; function connect() { const ws new WebSocket(WS_URL); ws.onopen () { reconnectDelay 1000; updateStatus(connected); }; ws.onclose () { updateStatus(disconnected); setTimeout(connect, reconnectDelay); reconnectDelay Math.min(reconnectDelay * 2, MAX_DELAY); }; ws.onerror () ws.close(); }同时面板上要有一个明显的连接状态指示器。我用的是页面顶部一条细横条绿色表示连接正常黄色表示正在重连红色表示断开。这个细节很重要因为如果连接断了但界面还显示着旧数据你可能会基于过时信息做决策。提示除了断线重连还要做心跳保活。每隔 30 秒发一个 ping服务端回 pong超过一定时间没收到 pong 就主动断开重连。很多中间设备会清理长时间无数据的连接心跳能避免这种假连接。3. 实操过程与核心环节实现3.1 环境准备与项目初始化先把项目骨架搭起来。我用的目录结构如下tick-stock-panel/ ├── server/ │ ├── index.js # WebSocket 服务端入口 │ ├── dataSource.js # 行情源接入 │ └── broadcaster.js # 数据广播 ├── client/ │ ├── index.html │ ├── panel.js # 面板主逻辑 │ ├── render.js # 渲染模块 │ └── style.css └── package.json服务端用 Node.js依赖只有ws这一个库负责 WebSocket 服务端。前端零依赖纯原生。初始化命令mkdir tick-stock-panel cd tick-stock-panel npm init -y npm install ws这个极简的依赖是有意为之。依赖越少出问题的环节越少部署也越简单。整个项目跑起来只需要 Node.js 环境不需要构建工具不需要打包改完代码刷新页面就生效。3.2 服务端数据分发实现服务端的核心逻辑是接收行情源数据广播给所有连接的前端。先看广播模块const WebSocket require(ws); class Broadcaster { constructor(port) { this.wss new WebSocket.Server({ port }); this.clients new Set(); this.wss.on(connection, (ws) { this.clients.add(ws); ws.on(close, () this.clients.delete(ws)); ws.on(message, (msg) this.handleClientMessage(ws, msg)); }); } handleClientMessage(ws, msg) { const data JSON.parse(msg); if (data.type ping) { ws.send(JSON.stringify({ type: pong })); } } broadcast(payload) { const message JSON.stringify(payload); this.clients.forEach((ws) { if (ws.readyState WebSocket.OPEN) { ws.send(message); } }); } }这里有个性能细节broadcast里先JSON.stringify一次然后发给所有客户端而不是每个客户端单独序列化。在客户端数量多的时候这个优化能省不少 CPU。另外发送前检查readyState避免往已关闭的连接写数据导致报错。3.3 行情源接入与数据清洗行情源接入层要处理的核心问题是格式转换和异常过滤。不同行情源的字段名、数值单位、时间格式都不一样接入层要把它们统一成标准格式。function normalize(rawData) { const price parseFloat(rawData.last_price || rawData.price); const prevClose parseFloat(rawData.pre_close || rawData.prevClose); if (!isFinite(price) || !isFinite(prevClose) || prevClose 0) { return null; // 异常数据丢弃 } const change price - prevClose; const changePercent (change / prevClose) * 100; return { symbol: String(rawData.symbol || rawData.code), name: rawData.name || , price: round(price, 2), prevClose: round(prevClose, 2), change: round(change, 2), changePercent: round(changePercent, 2), volume: parseInt(rawData.volume, 10) || 0, amount: parseFloat(rawData.amount) || 0, timestamp: rawData.timestamp || Date.now() }; } function round(num, digits) { const factor Math.pow(10, digits); return Math.round(num * factor) / factor; }异常过滤这块我要重点说。行情数据里经常出现脏数据价格是 0、昨收是 0、价格突然变成负数、成交量是字符串。这些数据如果直接推到前端轻则显示异常重则导致计算错误。所以接入层必须做校验不合格的数据直接丢弃宁可少显示也不能显示错的。注意prevClose 0的判断很重要。有些行情源在集合竞价阶段会推送昨收为 0 的数据如果不过滤涨跌幅计算会变成 Infinity前端显示就乱了。3.4 前端面板渲染实现前端渲染分两部分初始化时创建表格结构数据更新时只改变化的单元格。初始化function initPanel(symbols) { const tbody document.querySelector(#panel tbody); tbody.innerHTML ; symbols.forEach((symbol) { const tr document.createElement(tr); tr.id row-${symbol}; tr.innerHTML td classcol-symbol${symbol}/td td classcol-name/td td classcol-price/td td classcol-change/td td classcol-percent/td td classcol-volume/td ; tbody.appendChild(tr); }); }更新时只改文本内容和 class不重建 DOMfunction updateRow(symbol, data) { const tr document.getElementById(row-${symbol}); if (!tr) return; const priceCell tr.querySelector(.col-price); const prevPrice parseFloat(priceCell.textContent) || data.price; priceCell.textContent data.price.toFixed(2); tr.querySelector(.col-name).textContent data.name; tr.querySelector(.col-change).textContent data.change.toFixed(2); tr.querySelector(.col-percent).textContent data.changePercent.toFixed(2) %; tr.querySelector(.col-volume).textContent formatVolume(data.volume); // 颜色和闪烁 const colorClass data.change 0 ? up : data.change 0 ? down : flat; tr.className colorClass; if (data.price prevPrice) { flash(priceCell, flash-up); } else if (data.price prevPrice) { flash(priceCell, flash-down); } }formatVolume把成交量转成万手亿手这种易读格式这个细节对盯盘体验提升很大毕竟没人愿意去数一长串数字。3.5 参数计算与性能调优实录渲染间隔定多少合适我做了几组实测数据如下渲染间隔CPU 占用视觉延迟适用场景50ms高几乎无感超短线标的少于 20 个100ms中无感一般短线标的 20-50 个200ms低轻微常规监控标的 50-100 个500ms很低可感知中长线标的 100最终我默认用 200ms同时把这个值做成可配置项。如果你的标的少、追求极致实时改成 100ms 甚至 50ms 都行如果标的特别多、机器性能一般调到 500ms 也能用。另一个性能点是表格行数。浏览器渲染几百行表格本身就有开销如果标的超过 200 个建议做虚拟滚动只渲染可视区域内的行。不过对于大多数个人用户监控 50 个以内的标的足够了虚拟滚动属于过度设计我没做。4. 常见问题与排查技巧实录4.1 连接类问题速查实时面板的问题里连接类占了一大半。我整理了一个速查表现象可能原因排查方法解决一直显示重连中服务端没启动或端口错检查服务端进程和端口启动服务端核对端口连上后几秒就断心跳没做或被中间设备清理看断开时间是否规律加心跳保活部分客户端连不上连接数超限看服务端连接数提高上限或加连接池数据延迟越来越大消息积压看服务端发送队列加节流或丢弃旧数据其中数据延迟越来越大这个坑我踩过。原因是服务端广播速度超过了客户端处理速度消息在客户端缓冲区堆积。解决办法是在客户端也做节流或者服务端检测到客户端处理不过来时主动丢弃中间数据只推最新值。行情场景下旧数据本来就没意义丢旧保新是合理的。4.2 数据类问题排查数据类问题最隐蔽因为界面看起来正常但数值可能是错的。常见的几种涨跌幅算错。八成是昨收取错了或者除权除息日没做复权处理。排查方法是拿几个标的的手算结果跟面板对比对不上就查昨收字段。成交量单位混乱。有的行情源给的是股有的是手差 100 倍。这个必须在接入层统一我建议统一用手因为国内习惯如此。时间戳时区问题。如果行情源给的是 UTC 时间前端显示时没转本地时区就会出现数据来自未来或数据来自过去的怪象。统一用毫秒时间戳显示时再转本地时间。提示接入新行情源时先拿 3 到 5 个标的的数据手工核对一遍确认价格、昨收、成交量、时间戳都对再接入全量。这个习惯能帮你省下大量排查时间。4.3 渲染类问题与避坑技巧渲染类问题主要表现为卡顿、闪烁、错位。卡顿前面说了节流能解决大部分。闪烁通常是频繁改 class 导致的解决办法是合并 DOM 操作一次改完。错位一般是表格列宽没固定数据长度变化时列宽跳动给每列设固定宽度或用table-layout: fixed就能解决。还有一个容易被忽略的问题数字跳动导致的视觉疲劳。价格每秒变好几次如果每次都闪眼睛很快就累了。我的做法是只对超过一定幅度比如 0.1%的变化才闪烁微小波动只改数字不闪。这个阈值可以配置找到自己舒服的值。4.4 部署与长期运行的注意事项面板如果要 7x24 小时运行有几个点要注意。服务端要加进程守护崩了能自动拉起。日志要定期清理不然磁盘会被写满。内存要监控长时间运行如果有内存泄漏几天后就会 OOM。我自己的部署方式是服务端跑在一台常开的小主机上前端用浏览器全屏打开。浏览器标签页长时间运行也可能内存增长建议每天刷新一次页面或者用定时任务自动刷新。这些都是实际跑久了才会遇到的问题提前做好能省不少心。最后分享一个我个人的小习惯面板上除了行情数据我还会加一个数据最后更新时间的显示。如果这个时间超过 5 秒没变说明数据流可能断了即使连接状态显示正常也要警惕。这个小小的字段帮我发现过好几次隐蔽的数据中断问题。
