北京
React 擅长处理很多事情。但如果你尝试每秒向它推送数千个数据点，很快就会明白：React 不是消防水管，更像一根花园软管。强行灌入太多数据，要么草坪被淹（DOM 崩溃），要么水管爆裂（应用挂掉）。
还有一个与之相伴的现象：你的笔记本电脑有 8 到 16 个 CPU 核心，而 React 应用几乎总是只用其中 1 个。主线程要处理 JavaScript、DOM、布局和绘制准备，其他核心闲置，主线程却要艰难地维持 60fps 的帧预算。
这两个问题有相同的解法：让 React 远离热路径，同时用上不止一个线程。这套模式，也正是 Figma 画布引擎、彭博交易仪表盘，以及你见过的每一个生物信号查看器背后的架构。
一个真实场景：19 通道脑电波可视化
在一个项目中，我需要可视化 19 个 EEG（脑电波）通道，每个通道每秒发送约 1,000 个数据点。加起来每秒接近 19,000 次更新。如果把这些全部直接喂给 React，界面不只是变慢，而是会直接“晕倒”。
这篇文章要讲的，就是我最终落地的端到端架构：环形缓冲区（ring buffers）、Web Worker、共享内存、离主线程渲染，以及那些能在持续数小时高负载下保持稳定的具体模式。
前置知识要求
要最大化地利用这篇文章，你需要：
- 熟悉 React 18 或 19，能自如使用 useState、useEffect、useRef，并理解挂载与重新渲染的区别。
- TypeScript 基础，能流畅阅读类型注解。
- 对浏览器主线程和事件循环有大致了解。不需要写过 Web Worker，但知道“阻塞主线程”意味着什么，会让第三步更容易理解。
- 熟悉 Canvas 2D 或某个图表库是加分项，不是必需。只要在 canvas 上画过东西，就准备好了。
- 一台能运行现代 Chrome 或 Edge 的笔记本。示例依赖 SharedArrayBuffer、OffscreenCanvas 和 Atomics，这些需要基于 Chromium 的浏览器和跨源隔离（文章后面会讲到）。
你不需要有 Web Workers、环形缓冲区或 WebGL 的经验。这篇文章会在真实问题的语境中逐一介绍它们。
谁已经在用这套方案？
这篇文章里的模式不是实验性的。它们是生产级应用背后的架构，这些应用正在摄取和渲染高频数据：
- 交易和金融仪表盘（彭博、Hyperliquid、dYdX，以及每一个严肃的市场查看器）每秒通过 canvas 渲染的网格推送数千个价格 tick。
- Figma 在 worker 内的 WebAssembly 中运行整个画布引擎，主线程只用 React 渲染界面框架。
- Google Docs 和 Microsoft Loop 在 worker 中运行文档模型，DOM 只是投影层。
- LightningChart、uPlot、Plotly、ECharts 等图表库在 Canvas 或 WebGL 上绘制，React 只做包装。
- 生物信号和心电图（ECG）查看器，同样依赖这套离主线程渲染的思路。
这些产品的共同点，是把高频数据流挡在 React 的渲染周期之外，让主线程只做它擅长的事：处理用户交互和界面更新。数据采集、缓冲、绘制，全部交给 worker 和底层图形 API。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
