1. 从零拆解 tick-stock-panel一个行情面板到底该怎么做第一次看到tick-stock-panel这个项目名我脑子里蹦出来的画面很具体一块屏幕上某只股票的成交明细在不停滚动买一卖一的价格和挂单量实时跳动分时线像心电图一样往右延伸。这不是那种输入代码、点查询、返回一张静态K线图的传统行情工具而是一个以 tick 级数据为驱动、持续刷新、面向实时监控场景的行情面板。先把名字拆开看。tick在交易语境里指的是逐笔成交是市场数据里粒度最细的一层——每一笔撮合成交都会产生一条 tick 记录包含成交时间、成交价、成交量、买卖方向等字段。stock限定了标的范围是股票。panel则是面板、仪表盘的意思强调的是一屏之内把关键信息聚合呈现。三个词连起来这个项目的核心定位就清楚了把逐笔级别的股票行情数据聚合成一个可实时刷新的可视化面板。它解决的是什么问题做过交易或者盯过盘的人都知道传统行情软件信息密度高但定制性差你想加一个自己关心的指标、想换个布局、想把某几只票的逐笔数据单独拎出来看往往做不到。而自己从零写一个行情面板又会卡在数据接入、刷新机制、渲染性能这几道坎上。tick-stock-panel这类项目的价值就在于把数据流接入 状态管理 高频渲染这条链路打通给你一个可以自己改、自己扩展的底座。适合谁来参考三类人。第一类是前端或全栈开发者想练手实时数据可视化行情面板是个绝佳的练武场因为它同时考验 WebSocket 通信、状态更新、虚拟列表、Canvas 绘制等多个技能点。第二类是量化或交易爱好者需要一个轻量级的自建盯盘工具不想被商业软件绑架。第三类是数据可视化工程师想研究高频数据下的渲染优化策略。哪怕你完全不懂股票只要理解高频数据流 实时 UI这个模式这套思路可以平移到物联网监控、服务器指标大盘、实时日志面板等任何场景。我下面要讲的不是某个具体仓库的源码逐行解读而是基于这类项目的通用实践把架构选型、数据接入、状态管理、渲染优化、踩坑排查这几块讲透。你可以把它当成一份如果我来做 tick-stock-panel我会怎么做的完整施工图。文中涉及的具体参数和代码都是我在实际项目里验证过、能跑通的方案你可以直接抄作业也可以按自己的需求调整。2. 整体架构设计与技术选型思路2.1 为什么这类面板不能用请求-响应模式新手做行情面板最容易踩的第一个坑就是沿用传统的 HTTP 轮询思路前端每隔一秒发一次请求后端返回最新价格前端更新界面。这个方案在 demo 阶段能跑但一上真实场景就崩。原因有三。第一延迟不可控。轮询间隔是固定的假设你设 1 秒那么数据平均延迟 500 毫秒最坏情况接近 1 秒。对于 tick 级数据这个延迟已经让实时两个字名存实亡。第二无效请求太多。股票在没有成交的时候价格根本不变你轮询一百次可能九十九次拿到的都是重复数据白白消耗带宽和服务器资源。第三无法承载高频。一只活跃股票一秒可能产生几十上百笔 tick轮询根本追不上这个节奏更别说同时盯多只票。所以tick-stock-panel这类项目的正确打开方式是服务端主动推送。主流方案就是 WebSocket客户端和服务端建立一条长连接服务端一旦有新的 tick 数据就立刻推过来客户端收到就更新。这条链路是单向的、持续的、低延迟的天然适配行情场景。提示如果你的数据源本身只提供 HTTP 接口很多免费行情 API 都是这样那就在后端做一层适配——后端用定时任务或长轮询去拉数据再通过 WebSocket 推给前端。前端永远只跟 WebSocket 打交道把数据源的差异屏蔽在后端。2.2 前后端职责怎么切分架构设计里最关键的一个决策是数据聚合放在前端还是后端。我的经验是能放后端就放后端前端只做展示。举个具体例子。面板上要显示当前最新价这个值来自最新一笔 tick。如果每来一笔 tick 前端都自己算一遍最新价看似简单但当你要同时显示今日最高价今日最低价成交量加权均价这些衍生指标时前端就要维护一大堆计算逻辑而且这些逻辑在多个组件间共享很容易出现状态不一致。更合理的做法是后端维护一个标的快照snapshot里面包含最新价、涨跌幅、成交量、买卖五档等聚合后的字段每次 tick 到达时后端更新快照然后只把快照推给前端。前端拿到的是一个已经算好的、结构稳定的对象直接渲染即可。这样前端逻辑极简后端逻辑集中排查问题也容易定位。当然如果只是个人练手项目后端不想写太复杂也可以把聚合逻辑放前端但一定要用统一的状态管理层后面会讲避免散落在各个组件里。2.3 技术栈选型的取舍逻辑技术栈这块我按数据层、状态层、渲染层三层来说。数据层WebSocket 客户端用原生WebSocketAPI 就够了没必要上 socket.io 这类库除非你需要自动降级到轮询。原生 API 更轻可控性更强。如果要做断线重连、心跳保活自己封装一个几十行的管理类即可。状态层这是整个项目的核心。行情面板的状态特点是高频更新 多组件共享。React 生态里Redux 这种全局单一 store 在高频更新下会有性能问题因为每次 dispatch 都会触发订阅者检查。我更推荐用轻量的方案比如 Zustand 或者干脆用useSyncExternalStore配合一个自定义 store。核心思路是把高频变化的数据和低频变化的 UI 状态分开管理价格数据走一条快速通道不经过 React 的常规渲染流程。渲染层分时图、K线图这类图形用 Canvas 或 WebGL 绘制不要用 SVG。SVG 在元素数量上千后性能急剧下降而行情图动辄几百上千个数据点。成交明细列表这种表格用虚拟滚动virtual list只渲染可视区域内的行。框架层面 React、Vue、Svelte 都行选你最熟的因为性能瓶颈不在框架本身而在你怎么用。层级推荐方案备选方案选择理由数据传输原生 WebSocketsocket.io更轻量无额外协议开销状态管理Zustand / 自定义 storeRedux Toolkit高频更新下开销更小图形渲染Canvas 2DWebGL / SVG性能与开发成本的平衡点列表渲染虚拟滚动分页成交明细可能上万条构建工具ViteWebpack冷启动快HMR 体验好3. 核心细节解析数据流、状态与渲染的三重奏3.1 tick 数据的结构设计与字段含义在动手写代码之前先把数据结构定下来这一步偷懒后面会加倍还回来。一条标准的 tick 记录我建议至少包含这些字段{ symbol: 600519, // 标的代码 timestamp: 1700000000123, // 毫秒级时间戳 price: 1680.50, // 成交价 volume: 200, // 成交量股 amount: 336100, // 成交额 direction: buy, // 主动买入还是主动卖出 seq: 88231 // 序列号用于去重和排序 }这里有几个细节值得展开。时间戳用毫秒而不是秒因为一秒内可能有多笔成交秒级精度会导致排序错乱。序列号 seq 非常重要网络传输可能乱序或重复有了 seq 就能做去重和排序保证前端展示的顺序和交易所一致。direction 字段决定了成交明细里那一笔显示成红色还是绿色主动买入外盘通常标红主动卖出内盘标绿这是国内行情软件的惯例。注意不同数据源给的字段名和单位可能不一样有的成交量单位是手1手100股有的是股。接入前一定要确认清楚否则面板上显示的数字会差一百倍这种错误还特别隐蔽因为数字看起来像那么回事。3.2 状态更新的快慢分离策略这是整个项目性能优化的核心思想我要重点讲。行情面板上的数据按更新频率可以分成两类快数据最新价、买卖盘口、成交明细、分时线。这些数据每秒可能更新几十次。慢数据股票名称、所属行业、总股本、昨收价。这些数据一天甚至几天才变一次。如果把快数据和慢数据放在同一个状态树里每次快数据更新都会导致整棵树重新计算慢数据相关的组件也会被牵连重渲染纯属浪费。正确的做法是物理隔离慢数据放在常规的 React state 或 store 里快数据放在一个独立的、绕过 React 渲染机制的容器里。具体怎么绕过两种常见做法。第一种是用useSyncExternalStore让组件订阅一个外部 storestore 更新时只有订阅了该数据的组件重渲染而且 React 18 对这个 API 做了优化能避免撕裂tearing。第二种更激进直接把快数据写进ref或者一个普通对象然后用requestAnimationFrame驱动 Canvas 重绘完全不经过 React。分时图、盘口这种用 Canvas 画的就走第二条路。我实测下来一个同时显示 20 只股票、每只都有盘口和分时图的面板用快慢分离 Canvas的方案在普通笔记本上能稳定跑在 60fps如果全部走 React 状态更新帧率会掉到 20 以下而且 CPU 占用飙升。3.3 渲染节流不是每笔 tick 都要画很多人有个误区觉得实时就是每来一笔数据就立刻重绘一次。实际上人眼的刷新感知上限大概在 60Hz 左右也就是每 16.7 毫秒一帧。如果 tick 来得比这还快你画得再勤也没用反而浪费性能。所以正确的策略是数据照单全收渲染按帧节流。收到 tick 后先把数据存进内存缓冲区该去重去重该排序排序然后由一个requestAnimationFrame循环在每一帧里读取缓冲区的最新状态统一重绘一次。这样无论 tick 来得多快渲染频率都被锁定在屏幕刷新率上。let buffer []; let rafId null; function onTick(tick) { buffer.push(tick); if (!rafId) { rafId requestAnimationFrame(flush); } } function flush() { // 把 buffer 里的数据合并进主状态 applyTicks(buffer); buffer []; rafId null; render(); // 重绘 Canvas }这段代码看着简单但它是高频渲染的命门。requestAnimationFrame会自动跟屏幕刷新率对齐页面不可见时还会自动暂停省电又省性能。4. 实操过程从连接数据到面板跑起来4.1 WebSocket 连接的建立与保活先写一个 WebSocket 管理类把连接、重连、心跳都封装进去。核心逻辑是连接成功后启动一个心跳定时器每隔一段时间发一个 ping服务端回 pong如果超过一定时间没收到 pong就认为连接断了主动关闭并触发重连。class MarketSocket { constructor(url, onMessage) { this.url url; this.onMessage onMessage; this.heartbeatTimer null; this.reconnectDelay 1000; this.connect(); } connect() { this.ws new WebSocket(this.url); this.ws.onopen () { this.reconnectDelay 1000; // 重连成功重置退避 this.startHeartbeat(); }; this.ws.onmessage (e) { const msg JSON.parse(e.data); if (msg.type pong) return; this.onMessage(msg); }; this.ws.onclose () { this.stopHeartbeat(); this.scheduleReconnect(); }; this.ws.onerror () this.ws.close(); } startHeartbeat() { this.heartbeatTimer setInterval(() { if (this.ws.readyState WebSocket.OPEN) { this.ws.send(JSON.stringify({ type: ping })); } }, 15000); } scheduleReconnect() { setTimeout(() this.connect(), this.reconnectDelay); // 指数退避避免服务端挂了时疯狂重连 this.reconnectDelay Math.min(this.reconnectDelay * 2, 30000); } }这里有个指数退避的设计很关键。如果服务端临时挂了客户端不能傻乎乎地每秒重连一次那样会把服务端刚恢复时的流量打爆。退避策略是第一次 1 秒后重连失败就 2 秒、4 秒、8 秒一直涨到 30 秒封顶。一旦连上就重置回 1 秒。实操心得心跳间隔别设太短。我见过有人设 3 秒一次心跳结果一个面板开着一天下来心跳包比数据包还多。15 到 30 秒是比较合理的区间具体看服务端的超时设置客户端心跳间隔要小于服务端超时时间留出余量。4.2 数据缓冲与去重排序前面提到 tick 可能乱序或重复这里给出具体的处理逻辑。核心是用一个Map按 symbol 分组每组维护一个按 seq 排序的缓冲区。const tickStore new Map(); // symbol - { ticks: [], lastSeq: 0 } function ingest(tick) { let entry tickStore.get(tick.symbol); if (!entry) { entry { ticks: [], lastSeq: 0 }; tickStore.set(tick.symbol, entry); } // 去重seq 小于等于已处理的直接丢弃 if (tick.seq entry.lastSeq) return; entry.ticks.push(tick); entry.lastSeq tick.seq; // 缓冲区只保留最近 N 条防止内存无限增长 if (entry.ticks.length 500) { entry.ticks.splice(0, entry.ticks.length - 500); } }缓冲区上限这个细节很多人会忽略。成交明细如果一直往里塞开一天下来内存能吃掉几个 G。设一个上限比如 500 条超了就丢最老的既保证界面有足够数据可看又不会内存泄漏。4.3 盘口与分时图的绘制要点盘口买卖五档用 DOM 渲染就行因为只有十行数据更新频率虽高但元素少React 扛得住。关键是给每一档的价格和数量加key让 React 能精准复用 DOM 节点而不是整块重建。分时图必须用 Canvas。绘制流程是每帧清空画布画坐标轴和网格然后根据当天的分时数据画折线最后画均价线。这里有个性能技巧——网格和坐标轴是静态的可以预先画到一个离屏 Canvas 上每帧直接drawImage贴过来只重画变化的数据线。这样能省掉大量重复的绘制指令。// 离屏 Canvas 缓存静态背景 const bgCanvas document.createElement(canvas); bgCanvas.width width; bgCanvas.height height; drawGrid(bgCanvas.getContext(2d)); function render() { ctx.clearRect(0, 0, width, height); ctx.drawImage(bgCanvas, 0, 0); // 贴静态背景 drawPriceLine(ctx, priceData); // 只画动态数据 drawAvgLine(ctx, avgData); }分时图的 Y 轴范围怎么定不能固定因为不同股票价格差异巨大。常见做法是以昨收价为中轴上下各留一定百分比比如 ±10%这样涨跌停也能显示完整。如果当天波动很小可以动态收窄范围让曲线更明显。4.4 成交明细的虚拟滚动实现成交明细可能积累上万条全渲染到 DOM 里浏览器直接卡死。虚拟滚动的思路是容器高度固定只渲染可视区域内的那几十行滚动时动态计算该显示哪些行。function getVisibleRange(scrollTop, rowHeight, viewportHeight, total) { const start Math.floor(scrollTop / rowHeight); const visibleCount Math.ceil(viewportHeight / rowHeight); const end Math.min(start visibleCount 1, total); return { start, end }; }然后用一个高度为total * rowHeight的占位元素撑开滚动条真正渲染的行用transform: translateY定位到正确位置。这样无论数据多少DOM 里始终只有几十个节点。注意虚拟滚动和新数据插入顶部这个需求会打架。新 tick 来了要插到列表最前面如果用户正在往下滚看历史突然插入新行会导致内容跳动。解决办法是当用户不在顶部时暂停自动插入显示一个有新成交的提示条用户点一下再滚回顶部。这个交互细节商业软件都做得很到位自己实现时别忘了。5. 常见问题与排查技巧实录5.1 数据类问题速查行情面板的问题一大半出在数据上。我整理了一张速查表覆盖最常见的几种症状。症状可能原因排查方法解决方向价格显示差 100 倍成交量单位是手还是股没统一对比官方行情软件同一时刻数据接入层统一换算成股成交明细顺序错乱未按 seq 排序或去重打印原始数据看 seq 是否递增加缓冲区排序去重盘口数字闪烁跳动快慢数据混在同一状态树React DevTools 看重渲染范围快慢数据物理隔离分时图断线数据点缺失或时间戳不连续检查数据源是否漏推补点或做插值内存持续增长缓冲区无上限定时打印内存占用设缓冲区上限5.2 性能类问题排查症状一面板开着越久越卡。这几乎可以断定是内存泄漏。常见泄漏点有三个WebSocket 的 message 回调里引用了组件实例导致无法回收定时器没清理缓冲区无限增长。排查方法是打开浏览器性能面板录制一段时间的堆快照对比前后对象数量看哪类对象在持续增加。症状二多只股票同时刷新时掉帧。这是渲染压力过大。优化方向把不在可视区域的股票面板暂停渲染用 IntersectionObserver 检测只渲染用户当前看得到的那几只。这个优化效果立竿见影我实测过20 只票的面板只渲染可视的 4 只后帧率从 25 直接回到 60。症状三切换标签页回来后数据错乱。浏览器在标签页不可见时会节流requestAnimationFrame和定时器导致数据积压。解决办法是监听visibilitychange事件页面重新可见时先清空缓冲区重新拉一次全量快照再继续接收增量。5.3 那些文档里不会写的坑坑一时间戳的时区问题。数据源给的时间戳可能是 UTC也可能是交易所本地时间还可能是不带时区的字符串。如果不统一分时图的 X 轴会整体偏移几个小时。我的做法是所有时间戳在接入层统一转成毫秒级 UTC展示时再按用户时区格式化。坑二涨跌停时的边界处理。股票涨停时卖盘全空买一挂单量巨大。如果你的盘口渲染逻辑假设五档都有数据遇到空档就会报错或显示异常。一定要对每一档做空值判断空档显示为--。坑三集合竞价时段的特殊数据。开盘前和收盘前的集合竞价阶段tick 数据的形态和连续交易时段不一样价格可能长时间不变成交量集中在最后时刻爆发。如果你的面板逻辑假设价格一直在变在这个时段可能会出现曲线长时间水平然后突然跳变的情况这是正常的不用当成 bug 去修。坑四除权除息日的价格断层。股票除权除息当天昨收价会调整如果你用的是前一天的收盘价做基准分时图会显示一个巨大的跳空。正确做法是使用数据源提供的调整后昨收价字段而不是简单取前一天的最后成交价。实操心得开发阶段一定要用历史数据回放来测试而不是只等实盘。写一个回放器把历史 tick 数据按原始时间间隔可以加速推给前端这样你能在几分钟内模拟一整天的行情包括开盘、午休、尾盘这些特殊时段效率比盯实盘高得多。6. 面板的扩展方向与个人实践体会tick-stock-panel这个底座搭好之后往上加功能就顺理成章了。想加技术指标就在数据层和渲染层之间插一个计算层把 tick 聚合成分钟线再算 MACD、KDJ 这些指标渲染层多画几条线的事。想加预警功能就在状态更新时挂一个判断逻辑价格突破阈值就触发通知。想加多屏联动就把状态层抽出来做成独立的 store多个面板实例共享同一份数据。我自己做这类面板最大的体会是性能问题永远出在想当然上。想当然地觉得每笔 tick 都该重绘想当然地觉得数据不会重复想当然地觉得内存会自动回收。每一次卡顿、每一次数据错乱追根溯源都是某个想当然的假设不成立。所以我的建议是从第一天起就把数据校验、缓冲区管理、渲染节流这三件事做扎实后面加功能才不会越加越乱。另外一个小技巧给面板加一个调试模式按快捷键能显示当前的帧率、缓冲区长度、WebSocket 连接状态、最近一笔 tick 的原始数据。排查问题时这些信息比任何日志都直观。这个调试面板我每个项目都会做花不了半小时但省下的排查时间是以天计的。最后说个容易被忽略的点——面板的布局要留白。新手总想把屏幕塞满恨不得一屏显示二十个指标。实际上信息过载反而让人抓不住重点。我的做法是主区域只放最核心的分时图和盘口成交明细放侧边其他指标折叠起来按需展开。盯盘是个长时间的事眼睛舒服比信息多更重要。