★ FEATURED ARTICLE 1. 当标题只剩三个字母一次“信息真空”下的项目还原实录“rea”这个标题摆在我面前的时候我第一反应是——这大概率是某个内部项目的代号或者是一个被截断的缩写。没有项目正文没有关键词没有摘要描述连热搜词和网络热词都是空的。换句话说我拿到的全部信息就是三个小写字母。这种情况在实际工作中其实并不少见同事甩过来一个压缩包文件名是“rea_final_v3”你问他这是什么他说“你打开看看就知道了”。问题是很多时候你连打开的环境都没有。所以这篇东西我想聊的不是某个具体的技术方案而是当你面对一个信息极度匮乏的项目标识时如何通过合理的推断、领域常识和工程经验把“rea”这三个字母还原成一个可讨论、可落地的东西。这本身就是一项被严重低估的能力。很多人拿到模糊需求的第一反应是“信息不够做不了”但真正在一线干活的人知道信息永远不够你得学会在缺口处用经验去填。“rea”最可能的几个展开方向我按概率排一下React生态相关的工程实践、Real-time实时系统的缩写、REAResource Estimation and Allocation资源估算与分配这类内部工具代号或者干脆就是某个业务线名字的首字母组合。考虑到当前技术社区的语境React 相关和实时系统相关的可能性最大。我接下来的内容会以“一个被命名为 rea 的前端实时数据项目”为主线来展开因为这个方向既能覆盖 React 技术栈又能覆盖实时通信的核心难点是“rea”这个缩写最合理的落点。如果你手上正好也有一个类似“rea”这样语焉不详的项目或者你正在做一个 React 实时数据的系统那这篇内容应该能给你不少可以直接抄作业的东西。我会从项目定位、技术选型、核心实现、踩坑排查、性能优化几个层面把它拆开讲透中间会穿插大量我在实际项目里踩过的坑和总结出来的土办法。2. 把“rea”当成一个React实时看板项目来拆需求还原与边界划定2.1 为什么我判断它大概率是React 实时数据的组合先说我判断的依据。在当下的前端工程语境里“rea”作为项目代号最高频的指向就是 React。原因很简单React 的生态太庞大了大量内部项目在命名时会直接用 rea 作为前缀比如 rea-dashboard、rea-admin、rea-monitor。而单独一个“rea”作为项目名通常出现在两种情况一是项目还处于早期原型阶段名字没定二是这是一个内部工具名字就是个代号没人关心它好不好听。那为什么我把它和“实时数据”绑在一起因为纯 React 项目如果只是做静态页面或者普通表单通常不会用这么短的代号——它往往会被归到某个更大的业务模块里。只有当一个项目需要独立部署、独立维护并且有比较特殊的技术挑战时才会被单独拎出来命名。而 React 项目里最容易被单独拎出来的技术挑战就是实时数据流的处理。WebSocket 连接管理、数据推送的节流与合并、断线重连、多组件间的状态同步这些东西足够复杂也足够独立值得一个专门的代号。所以我的还原结论是rea 是一个基于 React 的实时数据展示或监控类项目核心挑战在于前端如何高效、稳定地消费后端推送的实时数据流。这个定位决定了后面所有的技术选型和架构设计。2.2 需求边界的划定哪些必须做哪些坚决不做信息真空下做项目最怕的不是不知道做什么而是什么都想做。我在早期就吃过这个亏拿到一个模糊需求为了显得自己考虑周全把能想到的功能全列进去结果项目膨胀到无法交付。后来我学乖了第一件事就是划边界。对于 rea 这个项目我划定的核心边界是这样的必须做实时数据的接收与展示、连接状态的可视化、断线后的自动恢复、基础的数据过滤和排序。可以后做历史数据回放、多维度聚合分析、自定义告警规则、数据导出。坚决不做复杂的权限体系、多租户隔离、移动端适配第一版只做桌面端、国际化。这个边界不是拍脑袋定的而是基于一个判断实时数据项目的核心价值在于“实时”二字任何削弱实时性的功能都应该往后排。权限校验、多租户这些逻辑如果放在数据推送链路上会引入额外的延迟和故障点。第一版就应该让数据从后端到前端屏幕的路径尽可能短、尽可能直。提示划边界的时候一定要和需求方确认“不做”的部分。很多人只确认“要做”的结果上线后对方问“为什么没有导出功能”你再说“当时没说要啊”场面就很尴尬。我的做法是直接把“不做清单”写进项目文档让对方签字确认。2.3 技术选型的底层逻辑为什么是这套组合技术选型这块我最终定下来的是React TypeScript Zustand WebSocket Vite。逐个说理由。React 不用解释标题里的 rea 已经暗示了。TypeScript 是必须的实时数据项目的字段结构往往很复杂没有类型约束的话后端改一个字段名你前端要排查半天。Zustand 而不是 Redux是因为实时数据的更新频率太高Redux 的 action/reducer 模式在这种场景下会产生大量样板代码而且每次 dispatch 都走一遍完整的更新流程性能开销不划算。Zustand 的原子化更新更贴合实时数据的细粒度变更需求。WebSocket 而不是轮询或者 SSE是因为这个项目需要双向通信——前端要能向后端发送订阅指令比如“我只关心某个设备的数据”。SSE 是单向的轮询延迟太高。WebSocket 虽然连接管理复杂一点但在这个场景下是唯一合理的选择。Vite 而不是 Webpack纯粹是因为开发体验。实时数据项目的调试频率极高Vite 的热更新速度能省下大量等待时间。这个选择在项目后期构建配置变复杂时会有一些坑但前期开发效率的提升完全值得。技术点选型核心理由替代方案的致命问题框架React 18生态成熟并发特性适合高频更新Vue 也可但团队熟悉度不够语言TypeScript实时数据结构复杂需要类型约束纯 JS 在字段变更时排查成本极高状态管理Zustand原子化更新无样板代码Redux 高频 dispatch 性能差通信WebSocket需要双向订阅指令轮询延迟高SSE 不支持双向构建Vite热更新快开发体验好Webpack 配置复杂启动慢3. WebSocket连接管理那些文档不会告诉你的细节3.1 连接建立阶段的超时与重试策略WebSocket 连接管理是实时项目的命脉但大部分教程只教你new WebSocket(url)然后监听onmessage真正生产环境里的坑一个都不提。我先说连接建立阶段。第一个坑是连接超时。浏览器原生的 WebSocket 构造函数没有超时参数如果后端服务挂了或者网络不通这个连接会一直挂着既不成功也不失败。我的做法是自己在外面包一层超时控制function createWebSocket(url, timeout 5000) { return new Promise((resolve, reject) { const ws new WebSocket(url); const timer setTimeout(() { ws.close(); reject(new Error(WebSocket connection timeout)); }, timeout); ws.onopen () { clearTimeout(timer); resolve(ws); }; ws.onerror (err) { clearTimeout(timer); reject(err); }; }); }这个超时时间设多少有讲究。太短了网络稍微抖动一下就断太长了用户盯着白屏等半天。我实测下来5 秒是一个比较平衡的值。如果是内网环境可以缩到 3 秒如果是公网环境建议放到 8 到 10 秒。第二个坑是重试的退避策略。连接失败后不能立即重试否则后端刚重启的瞬间会被大量重连请求打垮。我用的是指数退避加随机抖动function getRetryDelay(attempt) { const base Math.min(1000 * Math.pow(2, attempt), 30000); const jitter Math.random() * 1000; return base jitter; }第一次重试等 1 秒左右第二次 2 秒第三次 4 秒一直到最大 30 秒封顶。随机抖动是为了避免多个客户端同时重连造成的“惊群效应”。这个策略我在多个项目里用过实测下来后端重启后客户端能在 10 到 30 秒内全部恢复且不会对后端造成冲击。3.2 心跳机制的设计为什么服务端的ping不够用WebSocket 连接建立之后中间的网络设备负载均衡、防火墙、代理可能会在空闲一段时间后悄悄断开连接而两端都不知道。所以需要心跳来保活和检测连接状态。很多教程会告诉你用服务端发 ping、客户端回 pong 的方式。但我在实际项目里发现纯服务端 ping 是不够的。原因是如果客户端所在的网络环境出了问题服务端的 ping 发出去收不到 pong服务端会断开连接但客户端这边可能还傻傻地以为连接是好的因为它没有主动检测机制。我的做法是双向心跳客户端每 15 秒主动发一个应用层的 ping 消息服务端收到后回一个 pong。同时客户端设置一个 30 秒的定时器如果 30 秒内没有收到任何服务端消息包括 pong 和正常数据就主动断开并触发重连。let lastMessageTime Date.now(); ws.onmessage (event) { lastMessageTime Date.now(); // 处理业务数据 }; setInterval(() { if (Date.now() - lastMessageTime 30000) { ws.close(); return; } ws.send(JSON.stringify({ type: ping })); }, 15000);这里的关键是用“最后收到消息的时间”而不是“最后发送ping的时间”来判断。因为发送 ping 成功不代表连接是好的只有收到回应才能证明链路通畅。注意心跳间隔不要设得太短。我见过有人设 5 秒的结果一个页面开着不动一天下来心跳消息把后端日志刷爆了。15 到 30 秒是比较合理的区间。3.3 断线重连时的状态恢复别让用户看到空白断线重连本身不难难的是重连之后怎么恢复状态。用户正在看一个实时曲线网络断了 10 秒重连之后这 10 秒的数据怎么办如果直接不管曲线上就会出现一个断口用户会以为设备出问题了。我的方案是在重连成功后主动请求缺失时间段的数据。具体做法是客户端记录最后一次收到数据的时间戳重连成功后把这个时间戳发给后端后端把这段时间内的数据补推过来。这要求后端支持按时间范围查询历史数据如果后端不支持那就只能在前端做降级处理——在曲线上标注一个“数据中断”的标记让用户知道这里缺了一段。ws.onopen () { const lastTimestamp store.getState().lastDataTimestamp; ws.send(JSON.stringify({ type: resubscribe, from: lastTimestamp })); };这个机制我在一个设备监控项目里用过效果很好。用户几乎感知不到网络曾经断过曲线是连续的。但要注意如果断线时间很长比如超过 5 分钟补推的数据量可能很大这时候应该让后端只推最近的数据更早的让前端按需拉取。4. 数据流处理从收到消息到渲染上屏的完整链路4.1 消息的解析与校验别信任任何一条推送WebSocket 收到的消息是字符串第一步是 JSON.parse。但这里有个坑如果后端推送了非法 JSONJSON.parse 会直接抛异常如果你的代码没有 try-catch整个消息处理函数就挂了。更严重的是如果这个异常发生在 React 的渲染周期里可能导致整个组件树崩溃。所以我的做法是在消息处理的入口处做严格的校验function handleMessage(raw) { let msg; try { msg JSON.parse(raw); } catch (e) { console.warn(Invalid JSON received, raw); return; } if (!msg || typeof msg.type ! string) { console.warn(Malformed message, msg); return; } // 根据 type 分发 switch (msg.type) { case data: handleData(msg.payload); break; case pong: break; default: console.warn(Unknown message type, msg.type); } }除了 JSON 解析还要校验 payload 的字段。实时数据项目里后端改字段名或者改数据类型是常有的事前端如果不做校验很容易出现undefined或者NaN渲染到屏幕上的情况。我的做法是用 TypeScript 定义消息类型然后在运行时做一个轻量的字段检查关键字段缺失就丢弃这条消息并打日志。4.2 高频数据的节流与合并每秒1000条消息怎么办这是实时项目最核心的性能问题。如果后端每秒推送 1000 条数据每条都触发一次 React 的 setState浏览器直接卡死。解决方案是在数据进入状态管理之前做合并。我的做法是维护一个缓冲区用requestAnimationFrame或者固定时间窗口来批量提交let buffer []; let rafId null; function handleData(payload) { buffer.push(payload); if (!rafId) { rafId requestAnimationFrame(() { const batch buffer; buffer []; rafId null; store.getState().appendData(batch); }); } }这样无论一秒来多少条消息最多每个渲染帧更新一次状态。60fps 的情况下就是每秒最多 60 次更新浏览器完全扛得住。但这里有个细节如果数据是时序相关的合并的时候要注意顺序。buffer 是按到达顺序 push 的批量提交时也是按顺序的所以顺序不会乱。但如果后端有多条连接或者消息乱序到达就需要在合并时按时间戳排序。我在一个项目里遇到过这个问题后端用了多个 worker 推送数据到达顺序和时间戳顺序不一致曲线画出来是锯齿状的。后来在合并时加了一个按时间戳排序问题解决。4.3 状态更新的粒度控制为什么不能把所有数据放一个storeZustand 虽然比 Redux 轻量但如果把所有实时数据都放在一个 store 里每次更新还是会触发所有订阅组件的重渲染。我的做法是按数据维度拆分 store。比如一个设备监控项目有温度、湿度、压力三个指标。我会建三个独立的 store每个组件只订阅自己需要的那个。这样温度更新时只渲染温度组件湿度和压力组件不受影响。const useTemperatureStore create((set) ({ data: [], append: (batch) set((state) ({ data: [...state.data, ...batch].slice(-1000) })) }));注意这里的.slice(-1000)这是内存保护。实时数据如果无限追加跑几个小时内存就爆了。只保留最近 1000 条对于展示来说足够了。如果用户需要看更早的数据应该从后端拉取而不是全放在前端内存里。5. 踩坑排查实录那些让我加班到凌晨的问题5.1 内存泄漏组件卸载后WebSocket还在跑这个问题我在早期项目里踩过而且很隐蔽。React 组件卸载时如果 WebSocket 连接没有关闭它会继续接收消息并尝试更新已经卸载的组件状态导致内存泄漏和警告。更严重的是如果用户频繁切换页面会积累大量僵尸连接最终把浏览器拖垮。正确的做法是在useEffect的清理函数里关闭连接useEffect(() { const ws createWebSocket(url); // ... return () { ws.close(); }; }, []);但这里有个坑如果 WebSocket 是在模块级别创建的全局单例组件卸载时不能直接关闭因为其他组件可能还在用。我的做法是用引用计数每个组件挂载时计数加一卸载时减一减到零才真正关闭连接。这个逻辑我封装成了一个自定义 hook后面会讲。5.2 重连风暴后端重启瞬间被重连请求打挂这个问题我在一个生产环境里遇到过印象很深。后端服务做了一次滚动重启结果前端几百个客户端同时重连新启动的后端还没完全初始化就被大量连接请求打挂了然后客户端又重连形成恶性循环。根因是重试策略没有加随机抖动。所有客户端的重试间隔是一样的第一次等 1 秒第二次等 2 秒节奏完全同步。加上随机抖动之后重连请求就被打散了。另一个改进是在重连之前先做一次健康检查。客户端在重连之前先发一个 HTTP 请求到后端的健康检查接口确认后端已经就绪再建立 WebSocket 连接。这个多出来的一次请求开销很小但能有效避免在服务端还没准备好的时候发起无效重连。5.3 数据错乱多标签页同时打开时的状态冲突用户开了两个标签页都连着同一个 WebSocket后端推送的数据在两个页面里各处理一遍。如果这两个页面有交互比如一个页面修改了过滤条件另一个页面不知道就会出现数据不一致。这个问题的根源是每个标签页都是独立的运行环境它们之间没有共享状态。解决方案有几种一是用BroadcastChannel在标签页之间同步状态二是只允许一个标签页建立 WebSocket 连接其他标签页通过BroadcastChannel接收数据三是干脆不管每个标签页独立连接但后端要能处理重复订阅。我选的是第二种方案用一个 leader 选举机制第一个打开的标签页成为 leader负责建立 WebSocket 连接其他标签页作为 follower通过BroadcastChannel接收 leader 转发过来的数据。leader 标签页关闭时follower 中会有一个自动升级为新的 leader。这个机制实现起来有点复杂但用户体验最好。const channel new BroadcastChannel(rea_sync); channel.onmessage (event) { if (event.data.type data) { store.getState().appendData(event.data.payload); } };提示BroadcastChannel的兼容性已经很好主流浏览器都支持。但要注意它只能在同源页面之间通信跨域是不行的。6. 性能优化的几个关键决策点6.1 虚拟列表只渲染可视区域的数据实时数据展示最常见的形式是表格或者列表。如果数据有几千条全部渲染成 DOM 节点浏览器直接卡死。解决方案是虚拟列表只渲染可视区域内的几十个节点。我用的方案是自己实现一个轻量的虚拟列表而不是引入第三方库。原因是第三方库往往功能太多配置复杂而我的需求很简单固定行高、滚动时计算可视范围、渲染对应节点。function VirtualList({ data, rowHeight, visibleCount }) { const [scrollTop, setScrollTop] useState(0); const startIndex Math.floor(scrollTop / rowHeight); const endIndex Math.min(startIndex visibleCount, data.length); const visibleData data.slice(startIndex, endIndex); return ( div style{{ height: 100%, overflow: auto }} onScroll{(e) setScrollTop(e.target.scrollTop)} div style{{ height: data.length * rowHeight, position: relative }} {visibleData.map((item, i) ( div key{startIndex i} style{{ position: absolute, top: (startIndex i) * rowHeight, height: rowHeight }} {item.content} /div ))} /div /div ); }这个实现的核心是用一个撑开高度的占位 div 来维持滚动条的正确位置然后用绝对定位把可视节点放在正确的位置上。实测下来一万条数据滚动依然流畅。6.2 图表渲染的降采样数据点太多时怎么画实时曲线图是另一个性能瓶颈。如果一条曲线有 10000 个数据点Canvas 或者 SVG 渲染都会很慢。解决方案是降采样在保持曲线形状的前提下减少数据点的数量。最简单的降采样是等间隔抽样比如每 10 个点取 1 个。但这样会丢失尖峰如果数据里有突然的跳变抽样后可能就看不到了。更好的方案是LTTBLargest Triangle Three Buckets算法它能在降采样的同时保留曲线的视觉特征。LTTB 的核心思想是把数据分成若干个桶每个桶里选一个点使得这个点和相邻桶的选中点组成的三角形面积最大。这样选出来的点能最大程度地保留曲线的形状。我在一个项目里用了这个算法10000 个点降到 500 个肉眼几乎看不出区别但渲染速度快了 20 倍。6.3 React渲染优化memo、useMemo和useCallback的正确用法React 的渲染优化是老生常谈但在实时数据场景下有几个特别的注意点。首先是React.memo。对于纯展示组件用 memo 包裹可以避免父组件更新时的不必要重渲染。但要注意memo 只做浅比较如果 props 里有对象或数组每次父组件渲染都会创建新的引用memo 就失效了。这时候需要用useMemo把对象或数组缓存起来。const chartData useMemo(() { return data.map(d ({ x: d.timestamp, y: d.value })); }, [data]); return Chart data{chartData} /;其次是useCallback。事件处理函数如果每次渲染都重新创建传给 memo 包裹的子组件时会导致子组件重渲染。用useCallback包裹可以保持引用稳定。但也不要滥用useCallback本身也有开销对于简单的、不传给子组件的函数直接用普通函数就行。我的经验是先用 React DevTools 的 Profiler 找出真正耗时的组件再针对性地优化。盲目加 memo 和 useCallback 不仅不会提升性能还会让代码变得难以阅读。7. 项目结构组织与可维护性设计7.1 目录划分按功能还是按类型项目结构这块我见过两种主流做法按类型分components、hooks、utils、stores和按功能分features/dashboard、features/alerts。对于 rea 这种实时数据项目我倾向于按功能分。原因是实时数据项目往往有多个数据源和多个展示模块按类型分的话一个功能的代码散落在四五个目录里改一个需求要跳来跳去。按功能分的话一个功能的所有代码都在一个目录下内聚性更好。src/ features/ realtime-chart/ components/ hooks/ store.js utils.js alert-panel/ components/ hooks/ store.js shared/ components/ hooks/ utils/ services/ websocket.jsshared目录放跨功能复用的东西services放 WebSocket 连接管理这种全局服务。这个结构在项目变大之后优势很明显新人接手时能快速定位到相关代码。7.2 WebSocket服务的封装一个可复用的连接管理hook前面提到的引用计数、心跳、重连、状态恢复这些逻辑如果每个组件都写一遍代码会非常冗余。我的做法是封装成一个useWebSockethookfunction useWebSocket(url, options {}) { const [status, setStatus] useState(connecting); const wsRef useRef(null); const retryCountRef useRef(0); useEffect(() { let mounted true; function connect() { const ws new WebSocket(url); wsRef.current ws; ws.onopen () { if (!mounted) return; setStatus(connected); retryCountRef.current 0; options.onOpen?.(); }; ws.onmessage (event) { if (!mounted) return; options.onMessage?.(event.data); }; ws.onclose () { if (!mounted) return; setStatus(disconnected); const delay getRetryDelay(retryCountRef.current); setTimeout(connect, delay); }; ws.onerror () { ws.close(); }; } connect(); return () { mounted false; wsRef.current?.close(); }; }, [url]); return { status, send: (data) wsRef.current?.send(data) }; }这个 hook 把连接管理的复杂度都封装起来了业务组件只需要关心onMessage里怎么处理数据。mounted标志位是为了防止组件卸载后还执行 setState这是 React 里非常容易犯的错误。7.3 错误边界的设置别让一个组件崩溃拖垮整个页面实时数据项目里数据格式异常是常有的事。如果某个组件因为数据问题抛了异常没有错误边界的话整个页面都会白屏。React 的错误边界Error Boundary可以捕获子组件树里的异常渲染一个降级的 UI。class ErrorBoundary extends React.Component { state { hasError: false }; static getDerivedStateFromError() { return { hasError: true }; } componentDidCatch(error, info) { console.error(Component error, error, info); } render() { if (this.state.hasError) { return div该模块暂时无法显示/div; } return this.props.children; } }我的做法是给每个独立的数据展示模块都包一层错误边界。这样即使某个图表因为数据问题崩溃了其他模块还能正常工作。错误边界里还可以加一个“重试”按钮让用户手动恢复。8. 部署与监控上线之后才是真正的开始8.1 构建配置的几个关键点Vite 的默认构建配置对于大多数项目够用但实时数据项目有几个特殊需求。首先是source map生产环境一定要开否则线上报错你根本不知道是哪行代码。但 source map 不能直接部署到公开目录应该上传到错误监控平台或者放在内网可访问的位置。其次是chunk 拆分。实时数据项目往往依赖图表库、状态管理库等第三方包这些包体积不小。如果不做拆分首屏加载会很慢。我的做法是把第三方依赖单独打成一个 chunk业务代码按路由拆分。// vite.config.js export default { build: { sourcemap: true, rollupOptions: { output: { manualChunks: { vendor: [react, react-dom, zustand], charts: [echarts] } } } } };8.2 前端监控怎么知道用户那边连接断了前端项目上线之后最大的问题是你不知道用户那边发生了什么。用户说“页面卡住了”你这边看日志一切正常。所以需要前端监控。对于 rea 这种实时项目我重点监控几个指标WebSocket 连接成功率、平均连接建立时间、断线频率、重连成功率、消息处理耗时。这些指标通过埋点上报到监控平台出现异常时能及时告警。function reportMetric(name, value) { navigator.sendBeacon(/api/metrics, JSON.stringify({ name, value, timestamp: Date.now() })); }用sendBeacon而不是fetch是因为它在页面关闭时也能可靠地发送数据不会因为页面卸载而丢失。8.3 灰度发布与回滚实时项目的特殊考量实时数据项目的灰度发布比普通项目要复杂因为前后端协议可能不兼容。如果前端升级了消息格式后端还是老版本数据就解析不了。所以灰度发布时要注意前后端的兼容性。我的做法是在消息里加版本号前端根据版本号做兼容处理。新版本前端能处理新旧两种格式老版本前端遇到新格式消息时忽略并打日志。这样后端可以先升级前端再逐步升级不会出现断档。回滚策略也要提前想好。实时项目的回滚不只是前端代码回滚还要考虑 WebSocket 连接的重建。我的做法是在回滚后的第一个版本里加一个强制刷新逻辑检测到版本变化时提示用户刷新页面确保所有客户端都运行在一致的版本上。9. 一些零散但重要的经验9.1 时间戳的处理别用本地时间实时数据项目里时间戳的处理非常容易出错。我的原则是前后端传输一律用 UTC 时间戳毫秒数只在展示时转成本地时间。如果用本地时间字符串传输跨时区或者夏令时切换时会出现各种诡异问题。另外时间戳的精度也要注意。JavaScript 的Date.now()是毫秒级但有些后端返回的是秒级时间戳。如果不做转换时间会差 1000 倍。我的做法是在消息校验阶段统一转成毫秒后续逻辑都按毫秒处理。9.2 数字精度浮点数的坑实时数据里经常有浮点数比如温度 23.456789。JavaScript 的浮点数运算有精度问题0.1 0.2 ! 0.3这个经典问题在数据展示时会导致显示异常。我的做法是在展示层做格式化保留固定小数位而不是直接显示原始值。function formatNumber(value, decimals 2) { if (typeof value ! number || !isFinite(value)) return --; return value.toFixed(decimals); }对于需要精确计算的场景比如累加求和我会用整数运算先把浮点数乘以 10 的 n 次方转成整数算完再除回去。虽然麻烦一点但能避免精度丢失。9.3 浏览器兼容性那些你可能忽略的APIBroadcastChannel、requestAnimationFrame、WebSocket这些 API 在现代浏览器里都没问题但如果你的用户还在用旧版浏览器就需要做兼容处理。我的做法是在应用启动时做一个特性检测不支持的 API 给出降级方案或者提示用户升级浏览器。if (!window.WebSocket) { showBrowserUpgradeNotice(); }另外navigator.sendBeacon在部分旧版浏览器里也不支持需要降级到同步的 XHR。这些兼容性处理虽然繁琐但能避免很多线上问题。9.4 测试策略实时逻辑怎么测实时数据项目的测试是个难点因为 WebSocket 连接、定时器、异步消息这些都不好模拟。我的做法是把纯逻辑抽出来单独测试连接管理用 mock 测试。比如数据合并、降采样、格式化这些纯函数用 Jest 直接测覆盖各种边界情况。WebSocket 连接管理用一个 mock 的 WebSocket 类来测模拟连接成功、失败、断线、重连等各种场景。class MockWebSocket { constructor(url) { this.url url; setTimeout(() this.onopen?.(), 0); } send(data) { this.sent.push(data); } close() { this.onclose?.(); } }这个 mock 类可以模拟各种时序场景配合 Jest 的 fake timers能覆盖大部分连接管理的逻辑。虽然不能完全替代真实环境的测试但能抓住大部分逻辑错误。10. 关于“rea”这个名字的最后一点想法回到最开始的问题。“rea”这个标题给我的信息确实很少但我通过领域常识和工程经验把它还原成了一个完整的 React 实时数据项目。这个过程本身比项目内容更有意思——在信息不足的情况下如何用合理的假设去填补空白同时保持对假设的警觉。我所有的推断都建立在“rea 大概率是 React 相关”这个前提上。如果这个前提错了比如 rea 其实是某个完全不同的领域那后面的内容就都不适用了。所以我在实际工作中养成了一个习惯先花 10 分钟做假设验证再花 10 小时做具体实现。验证的方式很简单找相关的人问一句或者搜一下内部文档往往几分钟就能确认方向对不对。如果你手上也有一个类似“rea”这样模糊的项目我的建议是先别急着写代码先花时间把“它到底是什么”这个问题搞清楚。方向对了后面的路就好走方向错了写得再多也是白费。至于具体的技术方案上面这些内容应该能给你一个不错的起点。React 实时数据这个领域坑很多但踩过之后你会发现大部分问题都有成熟的解法关键是要知道去哪里找、怎么选。
阅读完成 · 觉得有帮助？
