★ FEATURED ARTICLE 1. 项目概述与核心思路1.1 为什么叫rea去年接手了一个内部数据可视化项目代号定为rea。这个名字不是拍脑袋取的拆开来看是 React Real-time Analytics 的组合缩写直译就是基于 React 的实时分析系统。当时业务方的原始诉求很简单希望把散落在几个数据源里的关键指标汇总到一个页面上运营和产品同学打开浏览器就能看到最新的业务走势不用再翻好几张表格手动拼数据。听起来像是一个标准的数据看板需求但真正动工后发现事情没那么轻松。数据源头有三种不同类型一种是内部接口返回结构相对规整一种是日志服务导出的半结构化数据字段时有时无还有一种是第三方平台提供的报表只能拉取固定粒度的汇总结果。把这些不同节奏、不同格式的数据统一展示到前端并且保证页面不卡、不白屏、不出错才是rea真正的核心挑战。这篇文章会把rea从零到落地的完整过程记录下来包括架构选型、工程化配置、实时数据链路的实现方式以及上线前后踩过的典型坑。适合正在做数据看板、监控大屏、运营中台这类前端项目的朋友参考哪怕你还没接触过实时数据场景里面的组件设计思路和性能优化手段也能直接借用到其他项目中。1.2 核心需求拆解与范围界定在写第一行代码之前我花了大概一周时间做需求梳理。这里要特别强调数据可视化项目的需求梳理永远比技术实现更值得花时间。业务方往往只会说做个大屏看数据但落到细节问题多到能写满几页纸。rea最终明确下来的核心需求有四条多数据源接入至少对接三个不同来源的数据各自刷新频率不同。实时性要求页面打开后数据自动更新不需要手动刷新更新延迟控制在 30 秒以内。可视化呈现核心指标用图表展示支持折线图、柱状图、数字卡片、简易排行榜。交付形态Web 端网页内部系统使用不需要兼容老旧浏览器但要保证 Chrome 最新版本的完整体验。另外我也明确了非目标范围不做复杂的权限体系不做多租户隔离不做移动端适配不做大屏硬编码分辨率。这些边界看起来很基础但实际推进中非常关键——很多项目做到一半开始膨胀就是因为边界没有提前划清楚。经过需求梳理项目的 MVP 形态逐渐清晰一个单页应用顶部是核心指标卡片中间是趋势折线图右侧是排行榜底部是明细数据表格。数据每 15 秒轮询一次刷新数据时不能出现页面闪烁。2. 技术选型与工程化配置2.1 技术栈选型对比与依据技术选型是rea第一个需要拍板的决策点。我的目标很明确团队熟悉度优先生态成熟度其次不追求新潮技术。最终确定的方案是 React 18 TypeScript Vite 5 Zustand Axios ECharts。这里逐个说下理由。React 就不用多解释了团队日常主力框架组件生态丰富周边工具链非常成熟。真正需要对比的是构建工具当时 Vite 5 已经发布了大半年稳定性和插件生态都经过了充分验证。从实际开发体验来说Vite 的冷启动和热更新速度比传统 Webpack 配置快一个数量级——rea工程的依赖数量在 500 个左右Webpack 冷启动需要 15 秒以上而 Vite 几乎两三秒就能进入开发状态。开发体验这东西一旦习惯了就很难回头。状态管理选了 Zustand 而不是 Redux。原因在于rea的状态结构并不复杂全局只需要维护原始数据快照、数据更新时间、指标计算状态这几个维度Redux 的样板代码在这个场景下明显偏重。Zustand 只要几行代码就能完成状态定义和订阅而且它对 TypeScript 的支持非常自然。数据可视化选择 ECharts主要原因有三个图表类型覆盖率极高折线图、仪表盘、桑基图都有现成实现主题定制能力强能适配内部系统的视觉风格体积可控按需引入后最终图表包的体积不到 500KB。工具库、请求库上没什么悬念——Axios 仍然是当前最稳妥的选择默认支持请求拦截、响应拦截、取消请求生态成熟资料多遇到问题基本不会卡住。2.2 工程化搭建的完整步骤工程初始化我直接用 Vite 官方脚手架命令如下pnpm create vite rea --template react-ts这里额外提一句——创建项目时建议直接用pnpm而不是 npm。pnpm 的磁盘占用更小安装速度更快更重要的是它默认的依赖隔离策略能避免很多莫名其妙的问题。同一个仓库里如果有多个项目pnpm 的硬链接机制还能让公共依赖只保存一份节省大量磁盘空间。初始化完成后我做的第一件事不是写业务代码而是把工程的地基搭好。首先是路径别名这是必须的。不然你的组件文件里会出现一大串../../../../这种反人类的引用。rea的路径别名配置就放在vite.config.ts里添加了一段import { defineConfig } from vite; import react from vitejs/plugin-react; import path from path; export default defineConfig({ plugins: [react()], resolve: { alias: { : path.resolve(__dirname, ./src), }, }, server: { port: 3000, host: true, }, });路径别名配置完之后需要同时修改tsconfig.json让 TypeScript 也能识别/这样的导入路径。这一步经常被忽略导致 Vite 能运行但编辑器却报红。正确的做法是在tsconfig.json的compilerOptions里加上{ compilerOptions: { baseUrl: ., paths: { /*: [src/*] } } }接下来是代码规范。很多人觉得 ESLint 和 Prettier 是形式主义但放到真实项目里没有代码规范约束的项目维护成本会在两周后开始指数级上升。rea采用的方案是 ESLint 负责代码质量检查未使用的变量、未处理的 Promise、危险的类型断言Prettier 负责格式统一缩进、引号、分号。两者配合用一条命令保证所有提交的代码都符合同一标准。我在package.json里配置了这样的脚本{ scripts: { lint: eslint src --ext .ts,.tsx, format: prettier --write \src/**/*.{ts,tsx,css,scss}\, prettier:check: prettier --check \src/**/*.{ts,tsx,css,scss}\ } }除了本地检查还强制加了提交前钩子husky lint-staged保证每次都只检查暂存区的代码避免一次性报出全项目几百个历史遗留问题。2.3 目录结构与基础代码组织rea的目录结构是经过思考的不是脚手架默认的全塞到 src 里那种简单粗暴。我参考了目前社区里比较成熟的 feature-based 结构rea/ ├── src/ │ ├── api/ # 接口请求层所有网络请求收敛到这个目录 │ ├── components/ # 通用组件不包含业务逻辑 │ ├── pages/ # 页面级组件 │ ├── stores/ # 全局状态管理Zustand │ ├── hooks/ # 通用自定义 Hooks │ ├── utils/ # 工具函数 │ ├── types/ # 全局类型定义 │ ├── constants/ # 常量配置 │ └── App.tsx把 api 单独拆一层是我最推荐的做法。业务代码里永远不应该直接写 Axios 请求所有的 URL、请求方法、入参出参类型都收敛在 api 目录里。这样后端接口一旦变动你只需要修改一个文件而不是全局搜索散落的请求代码。以获取指标数据为例rea的 api 层代码长这样import request from /utils/request; export interface MetricData { timestamp: number; metricName: string; value: number; dimensions: Recordstring, string; } export const fetchMetrics (params: { startTime: number; endTime: number }) { return request.getMetricData[](/api/metrics, { params }); };这里的request是一个基于 Axios 封装的实例统一注入了 baseURL、超时时间、token 等公共配置。响应拦截器统一处理错误码和登录态失效这样每个业务模块就不用重复写错误处理逻辑了。3. 核心功能实现实时数据链路3.1 数据接入层封装rea的核心是实时数据链路这是整个项目的技术重心也是我认为最值得展开讲的部分。实时数据接入的第一个决策是用 WebSocket 还是轮询。我认真评估过两种方案。WebSocket 的优势是服务端主动推送实时性最好还能省掉大量无效请求劣势是需要服务端配合改造而且一旦连接断开还需要处理断线重连、心跳保活、消息补偿等一堆复杂逻辑。轮询的优势是简单可靠前后端解耦劣势是存在无效请求和半个周期的数据延迟。rea最终选择了轮询原因很实在当时的后端团队排期紧张WebSocket 服务改造预计需要两个星期而轮询模式前端自己就能搞定而且业务场景的更新延迟要求是 30 秒15 秒轮询完全够用。很多技术方案不是选最好的而是选最合适的。数据接入层的封装我放在了一个自定义 Hook 里配合 Zustand 使用import { useEffect, useRef } from react; import { useAppStore } from /stores; import { fetchMetrics } from /api; const POLLING_INTERVAL 15000; export function useMetricsPolling() { const timerRef useRefReturnTypetypeof setInterval | null(null); const setMetrics useAppStore((state) state.setMetrics); const loadData async () { try { const now Date.now(); const startTime now - 24 * 60 * 60 * 1000; const data await fetchMetrics({ startTime, endTime: now }); setMetrics(data); } catch (error) { console.error([rea] 指标数据拉取失败:, error); } }; useEffect(() { loadData(); timerRef.current setInterval(loadData, POLLING_INTERVAL); return () { if (timerRef.current) { clearInterval(timerRef.current); } }; }, []); }这段代码的几个细节值得说下。timerRef用 ref 而不是普通变量是为了保证 effect 清理时能拿到最新的定时器引用组件卸载时清理定时器这是防止内存泄漏的基础操作请求的错误被捕获并打印日志而不是静默吞掉这样出问题时前端能第一时间在 console 里定位。3.2 状态更新与渲染性能策略数据拉回来之后怎么更新状态、怎么触发布局重绘是另一个容易出问题的环节。rea的页面布局了多个组件指标卡片区、图表区、排行榜、明细表格。如果用一个全局状态保存所有数据每次轮询返回后所有组件都会重新渲染。虽然 React 的 diff 算法已经足够快但 ECharts 的图表实例在数据变化后需要重新setOption如果每次都全量更新浏览器会在数据高频刷新时出现可感知的卡顿。我的优化策略是状态分片 选择性订阅。Zustand 天然支持按需订阅组件可以只选择自己关心的状态片段避免无关渲染export const useAppStore createAppState((set) ({ metrics: [], lastUpdated: 0, setMetrics: (data) set({ metrics: data, lastUpdated: Date.now(), }), }));在图表组件中我只需要订阅metrics的变化而不是整个 storeconst metrics useAppStore((state) state.metrics);这样做的效果非常明显当轮询数据返回时只有图表组件和指标卡片组件重新计算排行榜如果没有变化则完全跳过渲染。另外在更新策略上还有一个细节。对于数字指标卡片我做了差值动画——数字从旧值平滑滚动到新值这个动画如果直接用 React 的 state 实现每一帧都会触发重新渲染性能压力不小。更务实的做法是直接操作 DOM 的文本节点import { useEffect, useRef } from react; function useAnimatedNumber(value: number) { const ref useRefHTMLSpanElement(null); const previous useRef(value); useEffect(() { const el ref.current; if (!el) return; const start previous.current; const end value; const duration 600; const startTime performance.now(); const step (now: number) { const progress Math.min((now - startTime) / duration, 1); const current start (end - start) * (1 - Math.pow(1 - progress, 3)); el.textContent current.toFixed(0); if (progress 1) { requestAnimationFrame(step); } else { previous.current end; } }; requestAnimationFrame(step); }, [value]); return ref; }这个方案的优势在于动画过程完全不经过 React 的渲染周期所有帧操作都发生在requestAnimationFrame里性能开销可以忽略不计。即使数据每 15 秒更新一次页面上若干个数字同时滚动动画也不会造成任何卡顿。3.3 图表封装与视觉呈现ECharts 的使用方式如果直接写每个页面都会重复一大段初始化代码。我更倾向做一个统一的封装组件把初始化、更新、销毁、自适应这些生命周期全部收敛起来。rea里我封装了一个Chart组件核心逻辑如下import * as echarts from echarts/core; import { LineChart, BarChart } from echarts/charts; import { GridComponent, TooltipComponent, LegendComponent, } from echarts/components; import { CanvasRenderer } from echarts/renderers; echarts.use([ LineChart, BarChart, GridComponent, TooltipComponent, LegendComponent, CanvasRenderer, ]); interface ChartProps { option: echarts.EChartsOption; height?: number; onReady?: (instance: echarts.ECharts) void; } const Chart: React.FCChartProps ({ option, height 300, onReady }) { const containerRef useRefHTMLDivElement(null); const chartRef useRefecharts.ECharts | null(null); useEffect(() { if (!containerRef.current) return; const chart echarts.init(containerRef.current); chartRef.current chart; onReady?.(chart); const handleResize () chart.resize(); window.addEventListener(resize, handleResize); return () { window.removeEventListener(resize, handleResize); chart.dispose(); chartRef.current null; }; }, []); useEffect(() { chartRef.current?.setOption(option, true); }, [option]); return div ref{containerRef} style{{ height }} /; };这个封装有几个关键点。第一setOption的第二个参数传了true表示完全替换配置而不是合并这对于数据实时刷新的场景是必要的避免旧的配置残留导致渲染异常。第二ResizeObserver替代了window的resize监听这样当组件本身的容器尺寸变化时比如侧边栏折叠图表也能自动适配。第三组件卸载时调用dispose防止 ECharts 实例泄漏。实际业务中趋势折线图的数据格式是一个数组ECharts 的配置用函数方式生成const buildLineOption (metrics: MetricData[]) ({ tooltip: { trigger: axis, axisPointer: { type: cross }, }, grid: { left: 48, right: 24, top: 32, bottom: 32, }, xAxis: { type: time, axisLabel: { formatter: (value: number) new Date(value).toLocaleTimeString(zh-CN, { hour: 2-digit, minute: 2-digit, }), }, }, yAxis: { type: value, scale: true, }, series: [ { name: 核心指标, type: line, smooth: false, data: metrics.map((item) [item.timestamp, item.value]), showSymbol: false, lineStyle: { width: 2 }, areaStyle: { opacity: 0.08, }, }, ], });图表整体的视觉风格也需要统一。rea使用的是公司内部设计系统定下的中性色板主色是深蓝色调#2563EB辅助色是灰色系背景是极浅的灰#F6F7F9图表文字统一用#64748B。加上一个统一的深色 fontFamily 设置整个系统视觉上不会显得花哨专业感比较强。4. 性能优化与渲染瓶颈解析4.1 大数据量列表的渲染优化rea的明细表格区一开始用的是最简单的方式——把数据map渲染成表格行数据量不大时完全没问题。但真实场景里接口返回的明细数据经常一次就有 500 到 1000 条记录需要展示在表格中同时允许用户按时间筛选。如果直接把全部数据渲染成表格行DOM 节点数轻松超过 2000 个页面的滚动和交互都会出现明显掉帧。解决方案是虚拟滚动。虚拟滚动的核心思路很好理解只渲染可视区域内的那一小部分行其他不可见的行不生成 DOM 节点无论数据量多大页面上的实际节点数都保持在几十个。我用一个轻量级的虚拟列表实现替换了原本的表格interface VirtualListPropsT { items: T[]; itemHeight: number; height: number; renderRow: (item: T, index: number) React.ReactNode; } const VirtualList T,({ items, itemHeight, height, renderRow }: VirtualListPropsT) { const [scrollTop, setScrollTop] useState(0); const visibleCount Math.ceil(height / itemHeight); const startIndex Math.max(0, Math.floor(scrollTop / itemHeight) - 5); const endIndex Math.min(items.length, startIndex visibleCount 10); const visibleItems items.slice(startIndex, endIndex); const offsetY startIndex * itemHeight; return ( div style{{ height, overflowY: auto }} onScroll{(e) setScrollTop((e.target as HTMLDivElement).scrollTop)} div style{{ height: items.length * itemHeight, position: relative }} div style{{ transform: translateY(${offsetY}px) }} {visibleItems.map((item, index) renderRow(item, startIndex index) )} /div /div /div ); };这段代码里我加了 5 行和 10 行的预渲染缓冲overscan目的是让快速滚动时不会出现白屏闪烁。经过实测1 万条数据在虚拟列表下流畅度与几十条数据几乎没有区别。如果你的项目不需要用表格其实还有更省事的办法——直接引入成熟的虚拟表格库。但rea的明细表格需要自定义的样式和排序逻辑自研一个虚拟滚动方案反而更可控。4.2 减少无效轮询与后台页签优化轮询虽然简单但如果优化不到位会出现一个很尴尬的浪费用户在浏览器切到了其他页签rea仍然在后台每 15 秒拉一次数据网络请求白白发出完全没人看。优化方案是监听页面可见性切走时停止轮询回来时立即恢复并重新拉一次数据。这个优化能省掉约 80% 的无效请求。实现方式很简单在轮询 Hook 里加上对document.visibilitychange事件的监听useEffect(() { const handleVisibilityChange () { if (document.visibilityState visible) { loadData(); startPolling(); } else { stopPolling(); } }; document.addEventListener(visibilitychange, handleVisibilityChange); return () { document.removeEventListener(visibilitychange, handleVisibilityChange); stopPolling(); }; }, []);另一个容易忽略的点是轮询请求的竞态问题。如果某一次请求因为网络原因迟迟没有返回而下一秒定时器又触发了下一次请求会出现两个并发请求互相覆盖的问题。解决方法是利用 AbortController每次发起新请求前先取消上一次未完成的请求const controllerRef useRefAbortController | null(null); const loadData async () { controllerRef.current?.abort(); const controller new AbortController(); controllerRef.current controller; try { const data await fetchMetrics({ ... }, { signal: controller.signal }); setMetrics(data); } catch (error) { if ((error as Error).name AbortError) return; console.error([rea] 指标数据拉取失败:, error); } };这里有个细节需要特别小心取消上一个请求时捕获到的错误是AbortError必须静默忽略否则控制台会被Request canceled报错刷屏。4.3 构建产物优化rea经过开发、联调、测试后最终要面对生产环境的性能考验。我做了三件事来优化构建产物。第一按需引入 ECharts。这一点在之前的图表封装里已经体现通过echarts/core按需注册只引入用到的LineChart、BarChart和几个组件。打包后的体积从全量引入约 1.5MB 降到了不到 500KB。第二路由级别代码分割。rea虽然是单页应用但后续扩容后页面数量增多全量打包会让首屏加载时间直线上升。用React.lazy动态导入路由组件无关页面不会被打进首屏 bundleconst Dashboard React.lazy(() import(/pages/Dashboard)); const ReportPage React.lazy(() import(/pages/ReportPage)); Routes Route path/ element{ React.Suspense fallback{PageLoading /} Dashboard / /React.Suspense } / /Routes第三静态资源上传 CDN 并开启 gzip。图片、字体这类体积大、不常变的资源放到 CDN减轻源站压力文本类资源JS、CSS用 gzip 压缩生产环境部署后整个首屏资源的传输体积大约只有原始体积的 25%。这里补充一个真实的性能对比数据优化前首屏完成时间FCP在 4G 网络下约 3.2 秒优化后降到 1.4 秒左右。对于内部系统来说这个提升已经非常明显直接影响了用户的第一印象。5. 常见问题与排查避坑实录5.1 轮询数据导致页面卡顿第一个遇到的性能问题是在联调阶段每次轮询返回数据后页面会出现明显的掉帧。用 React DevTools 的 Profiler 一查发现渲染时间高达 300ms 以上主要耗时集中在图表组件和表格上。排查过程是这样的先确认是不是图表更新消耗过大——把 ECharts 的setOption注释掉重新跑轮询掉帧依然存在。再把表格数据渲染注释掉掉帧消失了。最后定位到问题在于表格的全量渲染500 条数据map后生成 500 个tr每次数据更新 React 都要重新协调这些节点。解决方案就是我前面提到的虚拟滚动。替换后渲染时间从 300ms 降到 20ms 左右问题彻底解决。经验总结遇到性能问题不要凭感觉猜用工具定位才能找到真正的瓶颈。React DevTools 的 Profiler 和浏览器开发者工具的性能面板是排查这类问题的最佳入手点。5.2 页面切换后台再回来图表数据错乱这个问题的现象是用户把浏览器切到其他页签待了几分钟切回来的时候某些图表的曲线出现了大段的断层或者跳变。原因是轮询在页面隐藏时被停止了切回来时立即拉了一次最新数据但中间漏掉的时段没有任何数据补给。图表因为时间轴不连续产生了看起来像断层的效果。解决思路有几种一是保持页面在后台也拉数据浪费请求二是切回来时拉取一个更长的时间范围来补数据复杂但效果最好三是接受现实不做处理。rea最终选择了比较折中的方案切回来时立即拉取最近五分钟的数据并把这段时间的数据与原有数据合并去重。这样即使暂停了一段时间切回来时也能保证曲线的连续性同时不会因为拉取过长时间跨度的数据而影响加载速度。实现上就是维护一个数据合并函数const mergeMetrics (oldData: MetricData[], newData: MetricData[]) { const map new Mapnumber, MetricData(); [...oldData, ...newData].forEach((item) { map.set(item.timestamp, item); }); return Array.from(map.values()).sort((a, b) a.timestamp - b.timestamp); };这个方案不够完美比如暂停时间超过一天依然会有缺口但足以覆盖绝大多数真实使用场景。遇到问题不一定追求最完美的方案务实的解决往往更符合项目节奏。5.3 ECharts 容器宽度初始为 0另一个高频问题是当图表所在的组件在初始化时处于隐藏状态比如在 Tab 页签里默认显示第一个 Tab而图表在第二个 TabECharts 初始化时拿到的容器宽度是 0图表渲染出来就会是 0 宽只有切换到对应 Tab 后才能看到。排查发现ECharts 实例初始化发生在组件挂载时但此时容器的offsetWidth是 0。解决方案是在 Tab 切换时主动触发图表的resize()方法。我的处理方式是给图表组件暴露一个刷新方法由 Tab 切换的回调调用const chartRef useRefChartHandle(null); const handleTabChange (key: string) { setActiveTab(key); if (key chartTab) { // 延迟一帧等 Tab 内容真正渲染完成后再触发 resize requestAnimationFrame(() { chartRef.current?.resize(); }); } };注意这里用了requestAnimationFrame而不是同步调用原因是 Tab 切换时 DOM 更新有一个异步过程必须等一帧让容器拿到正确的宽度后再 resize。5.4 组件卸载后轮询仍然触发最后一个值得记录的坑来自一个低级但常见的错误我在某个页面组件里引入了useMetricsPolling但组件销毁时忘了清理 Hook 里的定时器。结果就是这个页面从路由里被移除后轮询还在后台跑每 15 秒发一次请求既浪费资源又容易造成隐性的内存泄漏。这个问题的根治方案是在 Hook 的 effect 清理函数中清除定时器也就是我前面代码里写的return () { if (timerRef.current) { clearInterval(timerRef.current); } };同时也要确保Zustand store 的状态不会跨页面残留。在rea中我设计了一个 reset 方法在 Dashboard 卸载时调用把 store 里的旧数据清空useEffect(() { return () { useAppStore.getState().reset(); }; }, []);这个细节看似不重要但如果不处理你从 Dashboard 跳到其他页面再回来可能会看到旧数据闪烁一下再被新数据替换体验很差。6. 实测效果与复盘感悟经过一个多月的开发加上两周的联调和测试rea最终在内部环境上线。从使用反馈来看业务方最满意的点有三处一是打开页面自动更新数据的实时体验运营同学不用再手动刷新了二是虚拟滚动加持下的明细表格即使几千条数据翻起来也非常顺滑三是整体视觉的专业感层级清晰、图表干净。从数据上看上线后一周内的平均页面停留时长明显增加这说明用户愿意在这个页面上高频浏览和操作早期担心的做了没人用的问题没有出现。这次实践让我对数据处理类的项目有了新的认识技术难点往往不在单个功能而在于多个功能叠加后的系统行为。实时数据看板看起来只是轮询 图表的简单组合但真正落地时全局状态的合理组织、组件渲染的精细控制、定时器生命周期管理、页面可见性联动这些跨功能的综合设计才是决定项目质量的关键。最后分享一个经验给正在做类似项目的朋友上线后一定要加基础监控。rea在页面里埋了几个简单的性能打点——首屏渲染时间、轮询失败率、数据更新时间间隔。这样一旦线上出现问题可以快速定位是哪个环节出了问题而不是靠用户来反馈你才知道。内部系统往往没有专职的监控平台但哪怕只是在 console 打个 log也比什么都没有强。
阅读完成 · 觉得有帮助？
