Web数据可视化库选型避坑指南：性能、分析与兼容性实战-编程实验室

1. 为什么“主流 Web 高级数据可视化库”这个评测本身就是一个高风险动作？

我第一次接到“全评测全球主流 Web 高级数据可视化与分析库”这个需求时，心里其实是发怵的——不是因为技术难度，而是因为这个命题天然带着三个致命陷阱，而市面上90%的所谓“横向对比”文章，恰恰就栽在这三处。

第一个陷阱：把“能画图”等同于“能做分析”。Highcharts、ECharts、Chart.js 这些名字你肯定听过，它们确实能渲染漂亮的折线图、饼图、热力图；但如果你真拿它们去跑一个用户行为漏斗分析、做实时流式数据的异常检测、或者对接一个需要动态下钻到千万级明细的 OLAP 查询引擎，你会发现：它们连基础的数据预处理管道都得靠你自己手撸。真正的“高级分析能力”，从来不是画布上那几根线条的事，而是背后整套数据流编排、计算卸载、状态管理、交互语义建模的能力。比如，当你要在一张散点图上点击某个异常点，触发后端发起一个带时间窗口和维度过滤的聚合查询，并把结果以小倍数图（small multiples）形式叠加在原图右下角——这个动作里，前端库只负责“点击”和“渲染”，中间所有逻辑链路，才是决定项目成败的关键。

第二个陷阱：用静态截图代替真实场景压测。太多评测文章喜欢放四张并排的柱状图截图，标上“渲染性能对比（10万条数据）”，然后写一句“ECharts 耗时 320ms，Highcharts 耗时 410ms”。这毫无意义。真实业务里，你面对的从来不是“一次性加载10万条静态 JSON”，而是：用户拖拽时间轴，每秒触发3次增量查询；图表区域被缩放到 200% 后重新渲染；同时有5个联动视图在响应同一个筛选器变更；浏览器内存占用已超 800MB，GC 频繁触发……这些场景下，ECharts 的 canvas 渲染优势可能被其庞大的 DOM 事件监听器拖垮，而 Highcharts 的 SVG 模型反而因更轻量的重绘逻辑更稳。不跑真实业务链路，只比“单次渲染耗时”，就像只测汽车发动机空转转速，却从不看它爬坡、过弯、急刹的表现。

第三个陷阱：把“企业级”简单等同于“贵”或“文档厚”。很多文章一提“企业级”，就默认指向 Plotly Dash 或 Power BI Embedded，理由是“支持 SSO 登录”“有商业授权”“文档有 2000 页”。但我在给三家不同行业客户落地可视化平台时发现：真正卡住企业落地的，从来不是授权费用，而是“能否无缝嵌入现有权限体系”“是否支持离线缓存策略”“当后端 API 响应延迟超过 3s 时，前端 Loading 状态是否可自定义中断逻辑”。比如某金融客户要求所有图表必须支持“断网后仍可查看最近一次成功加载的数据快照”，这个需求，Plotly Dash 默认不支持，而基于 D3 + Web Workers 自研的轻量方案反而能快速满足——因为它把“数据快照”作为一级概念设计进状态机，而不是当成一个可选插件。

所以这篇评测，我决定彻底放弃“打分制”“排行榜”“截图对比”这种表面功夫。我会带你走进6个真实业务切口：

一个需要实时渲染 50 万点轨迹的物流调度大屏；
一个支持 200+ 维度自由拖拽的 BI 自助分析页；
一个嵌入到老旧 ERP 系统 iframe 中、仅允许 150KB JS 加载体积的报表模块；
一个需通过 WebAssembly 加速数学计算的科研级脑电波形分析工具；
一个面向老年用户的社区健康数据看板，要求所有交互必须支持键盘导航与高对比度模式；
一个部署在边缘设备（ARM Cortex-A53，512MB RAM）上的工业设备状态监控终端。

每个切口，我都用同一组原始数据（来自公开的 NYC Taxi Trip 数据集），在同一台测试机（MacBook Pro M1, 16GB RAM）上，跑通完整链路：数据获取 → 清洗 → 可视化绑定 → 交互响应 → 内存/帧率监控 → 错误恢复。不看官网宣传，不抄文档参数，只看它在真实毛刺、真实网络抖动、真实用户误操作下的表现。下面，我们直接进入第一个硬核战场。

2. 物流调度大屏实战：50 万点轨迹实时渲染，谁扛得住？

这是我在某同城即时配送平台做的真实项目。他们需要在指挥中心大屏上，实时显示全城 50 万辆电动车的位置轨迹，每辆车每 5 秒上报一次 GPS 坐标（经度、纬度、速度、方向、电池电量）。前端要实现：

地图底图（Mapbox GL）上叠加所有车辆点位，按电量颜色分级；
点击任意车辆，弹出该车最近 30 分钟的移动轨迹线；
拖拽地图或缩放时，点位密度自动调节（避免密集区糊成一片）；
整体帧率 ≥ 55fps，内存增长 ≤ 50MB/小时。

这不是炫技，而是生死线——调度员靠这个画面判断运力缺口，延迟超过 2 秒，就可能错过一个订单。

2.1 技术选型逻辑：为什么 Canvas 是唯一解？

先说结论：在这个场景下，SVG 和 WebGL 都被排除，最终方案是纯 Canvas + Web Worker + Mapbox 自定义图层。原因很现实：

SVG 不可行：50 万个<circle>元素，DOM 树深度爆炸，Chrome 直接卡死。即使你用<g>分组、用transform批量移动，重绘时浏览器仍要遍历全部节点计算样式、布局、绘制顺序。实测：加载 10 万点 SVG，内存飙升至 1.2GB，帧率跌到 8fps，且无法回收——删除节点后内存不释放，这是 SVG 的固有缺陷。
WebGL 看似合理，实则掉坑：Three.js 或 Deck.gl 确实能轻松渲染百万点，但它们和 Mapbox GL 的坐标系、投影算法、缩放逻辑完全不兼容。强行桥接，你需要自己实现一套“经纬度 ↔ WebGL 归一化设备坐标”的转换矩阵，还要处理 Mapbox 的瓦片加载、旋转、倾斜等状态同步。我试过用 Deck.gl 的GeoJsonLayer叠加在 Mapbox 上，结果是：地图缩放时，点位漂移 200 米以上，且无法响应 Mapbox 的moveend事件做精准重绘。这不是性能问题，而是架构层面的不匹配。
Canvas 是唯一正解：它不产生 DOM 节点，所有像素由 JS 直接控制；Mapbox GL 提供CustomLayerInterface，允许你把 Canvas 作为图层插入，共享其投影、缩放、平移状态。你只需在render()回调里，根据当前视图范围（map.getBounds()）计算哪些点在可视区域内，再用ctx.drawImage()或ctx.fillRect()绘制。关键在于：Canvas 本身不管理数据，它只是一块画布；数据管理、坐标转换、可见性裁剪，全由你掌控。

提示：别信“Canvas 性能差”的老黄历。现代浏览器对 Canvas 2D API 优化极好，尤其是ctx.setTransform()+ctx.drawImage()批量绘制。真正拖慢的是频繁的ctx.beginPath()→ctx.arc()→ctx.fill()循环。正确做法是：预生成所有点的屏幕坐标（用 Web Worker 计算），存入 TypedArray（如Float32Array），再用ctx.putImageData()或ctx.drawImage()一次性贴图。

2.2 实测六库：在真实大屏链路中的表现

我用同一份 NYC Taxi 数据（50 万条记录，含pickup_lon,pickup_lat,speed,battery字段），在相同硬件上，分别接入以下六个库，跑通完整流程（数据加载 → 坐标转换 → Canvas 绘制 → 交互响应）：

库名	是否原生支持 Canvas 渲染	是否提供 Mapbox 集成方案	50 万点初始渲染耗时	持续运行 1 小时内存增长	拖拽缩放平均帧率	点击单点触发轨迹线耗时	关键缺陷
ECharts	✅（`canvas`renderer）	⚠️（需手动`setOption`更新，无原生 Mapbox layer）	1.8s	+320MB	42fps	850ms（需重绘整个图表）	轨迹线为新图表，与主图坐标系不一致，需手动同步缩放
Highcharts	❌（仅 SVG / VML）	❌（无 Mapbox 支持）	——（OOM 崩溃）	——	——	——	50 万点直接触发浏览器内存警告，强制终止
Chart.js	✅（`canvas`backend）	❌（无地理坐标支持）	2.3s	+410MB	38fps	1200ms（重绘开销大）	无地理投影能力，经纬度被当普通 XY 坐标，严重失真
Plotly.js	✅（`webgl`/`svg`，`canvas`需 hack）	⚠️（`mapbox`trace 类型，但仅支持基础 marker）	3.1s	+580MB	35fps	950ms	`mapbox`trace 不支持自定义 marker 图标（如电池图标），且无法响应 click 事件获取原始数据索引
D3.js	✅（完全可控）	✅（`d3-geo`+`mapbox-gl-js`官方示例）	1.2s	+85MB	58fps	210ms（仅重绘轨迹线）	需手写全部逻辑，无开箱即用的轨迹动画、缩放适配
Apache ECharts GL	✅（WebGL 渲染）	✅（官方`echarts-gl`+`mapbox-gl-js`插件）	0.9s	+120MB	62fps	330ms	`scatter3D`在 Mapbox 上渲染时，Z 轴（高度）与 Mapbox 的海拔模型冲突，导致点悬浮在空中

关键发现：

D3.js 赢在可控性，输在开发成本。它没有“库”的包袱，所有代码为你所控：坐标转换用d3.geoMercator()，可见性裁剪用d3.geoBounds()，点位绘制用ctx.fillStyle = getColor(datum.battery)+ctx.fillRect(x, y, 4, 4)。但你要自己实现轨迹线的贝塞尔插值、抗锯齿、以及与 Mapbox 视图变化的同步（监听map.on('move', updateCanvas)）。一个熟练前端，2 天能跑通 MVP；但后续维护、升级、兼容新 Mapbox 版本，全是隐形成本。
ECharts GL 表面最快，实际最危险。0.9s 渲染看似无敌，但它把所有计算扔给 GPU，一旦用户开启“开发者工具”或切换到低功耗模式，GPU 频率下降，帧率瞬间跌到 20fps，且无降级机制——它不会自动切回 CPU 渲染，而是直接卡死。我在客户现场就遇到过：大屏用 Intel 核显驱动，ECharts GL 渲染后 10 分钟，GPU 温度报警，系统强制降频，整个大屏变 PPT。
Highcharts 的“失败”最有价值。它根本没跑起来，但这恰恰证明了：当数据规模突破临界点，任何试图用通用图表库“硬扛”的方案，都是饮鸩止渴。它的崩溃日志明确提示RangeError: Maximum call stack size exceeded，根源是其 SVG 渲染引擎内部递归过深。这提醒你：选型前，必须先做“压力探针”——用真实数据量、真实交互频率，跑一个最小闭环，而不是看官网 Demo。

2.3 我的最终方案：D3 + Web Worker + Mapbox Custom Layer

基于实测，我放弃了所有“开箱即用”的库，选择了 D3 作为底层绘制引擎，但做了三项关键增强：

坐标转换卸载到 Web Worker：
主线程只负责 UI 和事件，所有经纬度 → 屏幕坐标的计算（含 Mapbox 的project()方法调用）放在 Worker 里。Worker 接收map.getBounds()和原始数据数组，返回一个Uint16Array，存所有点的(x, y, colorIndex)，主线程直接ctx.putImageData()绘制。实测：CPU 占用从 95% 降到 35%，且主线程永不卡顿。
动态点密度控制（LOD）：
不是简单地“显示/隐藏”，而是根据当前缩放级别，动态调整采样率。Zoom 12 以下（城市级），显示全部 50 万点；Zoom 13-15（街区级），用d3.bin()对点位做空间聚类，每个聚类用一个圆圈表示数量；Zoom 16 以上（楼宇级），只显示被选中车辆的精确点位。聚类算法用d3-hexbin，预计算好，避免实时计算。
轨迹线的“懒加载”与缓存：
点击车辆时，不立即请求后端，而是先检查本地 IndexedDB 是否有该车最近 30 分钟的轨迹缓存（Key:vehicle_id + timestamp_range）。有则秒出；无则发请求，同时在 Canvas 上画一个“加载中”的旋转圆弧。缓存 TTL 设为 5 分钟，避免 stale data。

这套方案上线后，客户大屏稳定运行 18 个月，零故障。它不酷炫，没有 fancy 的 3D 效果，但像一台柴油发动机——不声不响，永远可靠。

3. BI 自助分析页：200+ 维度自由拖拽，分析库的“元能力”在哪？

如果说大屏考验的是“吞吐量”，那么 BI 自助分析页考验的就是“表达力”——用户要能像搭积木一样，把任意维度（地区、时间、产品线、渠道、用户等级……）拖到行、列、颜色、大小、筛选器区域，系统实时生成对应图表，并支持下钻、联动、计算字段。这不是“画图”，而是构建一个微型的、可视化的 SQL 引擎。

我参与过两个典型项目：

电商公司：销售分析页，支持 237 个业务维度，用户可自定义“复购率”计算字段（COUNT(DISTINCT returning_users) / COUNT(DISTINCT all_users)）；
医疗 SaaS：临床试验数据看板，支持 189 个医学指标维度，需实时计算“患者脱落率”（按周、按中心、按治疗组多维下钻）。

这类场景，库的“高级分析能力”体现在三个层面：数据模型抽象能力、计算表达式引擎、可视化语义映射能力。不是谁 API 多，而是谁能把“用户拖一个字段”这件事，翻译成背后一整套数据流。

3.1 数据模型抽象：为什么 “Table Schema” 比 “Chart Config” 更重要？

大多数库的配置，是围绕“图表怎么画”展开的：series: [{type: 'bar', data: [...] }]。但 BI 分析的核心，是“数据怎么组织”。比如，用户拖入region（地区）和revenue（收入），系统要自动识别：region是维度（categorical），revenue是度量（numeric aggregate），默认聚合方式是SUM。如果用户再拖入date（日期），系统要自动识别时间粒度（天/月/年），并启用时间序列分析模式。

这就要求库底层必须有一个显式的、可扩展的数据模型（Data Model），而不是把数据当黑盒数组处理。我对比了各库的数据抽象层级：

ECharts / Chart.js / Highcharts：无内置数据模型。你传给它的data，就是最终渲染用的扁平数组。想实现拖拽分析？你得自己写一个“维度-度量解析器”，把用户拖入的字段，映射成groupby、agg、pivot操作，再调用setOption()刷新。这意味着：你的 BI 逻辑，90% 在库外实现，库只干最后 10% 的渲染。
Plotly Dash：有dash_table和dcc.Graph，但数据模型在 Python 后端（Pandas DataFrame）。前端只是展示层，所有计算（df.groupby().sum()）都在服务端完成。好处是计算能力强，坏处是每次拖拽都要发请求，延迟感强，且无法离线使用。
Apache Superset（前端用 ECharts）：它自己实现了完整的Dataset模型，包含字段类型（string/date/number）、语义类型（dimension/metric）、聚合函数（sum/count/avg/distinct_count）、时间粒度（day/month/year）。但这个模型是 Superset 自己的，ECharts 只是渲染器，不感知模型。
Lightweight BI 工具（如 Cube.js 前端 SDK）：这才是理想形态。Cube.js 定义了schema（星型模型），前端 SDK 提供cubejs实例，你调用cubejs.load({dimensions: ['Users.country'], measures: ['Users.count']})，它自动构造 SQL、发请求、缓存结果、处理错误。可视化层（如 React + Recharts）只接收resultSet.tablePivot()的结构化数据。模型在 SDK，渲染在组件，职责清晰。

注意：很多文章吹嘘“XX 库支持 OLAP”，其实只是它能接收 JSON 数据。真正的 OLAP 支持，是指它能理解drilldown、rollup、slicing这些操作语义，并与后端 Cube 服务通信。ECharts 本身不支持，但你可以用echarts-for-react+cubejs-react组合实现。

3.2 计算表达式引擎：用户写的 “SUM(revenue) / COUNT(DISTINCT user_id)” 谁来执行？

BI 用户最常做的，就是写计算字段（Calculated Field）。比如：“客单价 = SUM(revenue) / COUNT(DISTINCT order_id)”。这个表达式，不能只在前端 JS 里 eval——数据量大时，COUNT(DISTINCT)会 OOM；且结果必须与后端一致，否则审计出问题。

实测方案对比：

方案	执行位置	优点	缺点	适用场景
前端 JS Eval（如 math.js）	浏览器	快，无网络延迟	数据量 > 10 万行易卡死；无法保证与后端一致；无权限控制	小数据量、原型验证
后端 SQL 动态生成（如 Superset）	数据库	结果权威；可利用数据库索引；支持复杂函数	每次修改都要发请求；无法离线；SQL 注入风险需严格校验	企业级 BI，数据敏感
Wasm 编译的轻量引擎（如 DuckDB-WASM）	浏览器	本地执行，速度快；SQL 兼容性好；内存可控	初始加载 2MB WASM；不支持所有 SQL 函数；需预编译 schema	中等数据量（< 100 万行），需离线分析
Cube.js Query Engine	前端 SDK	基于预定义 schema，安全；支持缓存；可降级到前端计算	依赖 Cube 后端；schema 需提前定义	已有 Cube 基础设施的团队

我在医疗项目中，最终选了Cube.js + DuckDB-WASM 双引擎：

日常分析（< 50 万行），用 Cube.js 从 Presto 查询，结果缓存；
紧急排查（需临时 join 3 张表，且 Presto 慢），用户点击“离线分析”，前端自动下载相关表的 Parquet 文件，用 DuckDB-WASM 执行SELECT AVG(age) FROM patients JOIN trials ON ...，10 秒内出结果。
两者共用同一套schema定义，保证语义一致。用户无感知，只看到一个“闪电图标”切换按钮。

3.3 可视化语义映射：为什么 “拖到颜色” 和 “拖到大小” 不能是同一个 API？

用户拖一个字段到“颜色”区域，期望是：不同值用不同颜色区分（分类）；拖到“大小”区域，期望是：数值越大，图形越大（量化）。这背后是两种完全不同的视觉编码（Visual Encoding）规则。

分类编码（Nominal）：如product_category，需离散色阶（d3.scaleOrdinal()），且支持自定义顺序、缺失值颜色。
序数编码（Ordinal）：如priority_level（高/中/低），需有序色阶（d3.scaleOrdinal().domain(['high','medium','low'])）。
定量编码（Quantitative）：如revenue，需连续色阶（d3.scaleLinear()）或面积缩放（d3.scalePow().exponent(2)，因面积 ∝ 半径²）。

很多库（如 ECharts）用一个visualMap配置项覆盖所有情况，但实际使用中，用户会混淆：把revenue拖到颜色，结果得到一堆渐变色，看不出高低；把region拖到大小，结果某些地区圆点巨大，其他消失——因为库没做类型推断，直接用了scaleLinear。

我的解决方案是：在拖拽入口处，做字段类型强校验。

前端维护一个fieldTypeMap：{ 'revenue': 'measure', 'region': 'dimension', 'date': 'time' }；
当用户拖入，立即检查字段类型，并锁定可用的视觉通道：
- measure→ 可拖到color（连续色阶）、size（面积缩放）、label（数值标注）；
- dimension→ 可拖到color（离散色阶）、shape（不同图标）、row/column（分面）；
- time→ 可拖到xAxis（时间轴）、filter（时间范围筛选）。
如果用户强行拖错（如把region拖到size），弹出友好提示：“‘地区’是分类字段，不能用于大小编码，请拖到‘颜色’或‘行’区域”。

这个设计，让非技术人员也能正确使用，减少了 70% 的客服咨询。

4. 老旧 ERP 系统嵌入：150KB JS 限制下的可视化生存战

这是最让我头皮发麻的场景——把可视化模块嵌入到一个 2008 年上线、至今未重构的 Java Web ERP 系统。客户明确要求：

必须用<iframe>嵌入，不能改 ERP 前端；
加载的 JS 文件总大小 ≤ 150KB（gzip 后）；
兼容 IE11（是的，IE11）；
所有请求必须带X-ERP-Auth-Tokenheader；
不能引入任何第三方 CDN，所有资源走 ERP 内网域名。

这不是技术选型，这是考古发掘。你得在废墟里，用捡来的砖头，盖一座能用的房子。

4.1 为什么主流库全军覆没？

先看数据：

ECharts：完整版 1.2MB，精简版（tree-shaking）仍 420KB；IE11 需额外core-jspolyfill，+180KB；
Chart.js：3.9.1 版本 120KB，但依赖moment.js（30KB）处理时间，且 IE11 下Promise、fetch需 polyfill（+65KB），超限；
Highcharts：官方声称“支持 IE11”，但其highcharts.js本身 380KB，且必须搭配highcharts-more.js（+80KB）才能用热力图；
Plotly.js：最小 bundle 520KB，且依赖webgl，IE11 不支持；
D3.js v7：核心模块 110KB，但d3-array、d3-scale、d3-axis等常用模块加起来 280KB；
Lightweight 替代品（如 uPlot）：uPlot 本身仅 12KB，但无地理、无时间轴、无主题定制，需自己补全。

所有“现代”库，都在这个场景下跪了。它们的设计哲学是“功能完备”，而 ERP 嵌入的需求是“极致精简”。

4.2 我的“考古级”方案：Vanilla JS + SVG 手写 + Service Worker 缓存

既然库不行，那就回归本质：用原生 API，只实现必需功能。目标：一个能显示折线图、柱状图、饼图的报表模块，支持基本交互（hover tooltip、click drilldown），JS 总大小 ≤ 148KB。

技术栈选择逻辑：

渲染引擎：SVG（不是 Canvas）。理由：IE11 原生支持 SVG，且 SVG 元素自带title标签，hover tooltip 一行代码搞定（<title>Revenue: $1.2M</title>），无需 JS 监听；Canvas 在 IE11 下需excanvas，增加 80KB。
数据处理：Vanilla JS。不用 Lodash，手写groupBy、sumBy、maxBy，每个函数 < 50 行，总代码 3KB。
HTTP 请求：XMLHttpRequest（不是 fetch）。IE11 不支持 fetch，且xhr更轻量，polyfill 为 0。
认证头：全局 XHR Hook。在XMLHttpRequest.prototype.open上 monkey patch，自动注入X-ERP-Auth-Token，避免每个请求手动写。
缓存：Service Worker（IE11 不支持？没关系，用localStoragefallback）。SW 用于缓存图表配置 JSON；IE11 用localStorage.setItem('chartConfig', JSON.stringify(config))。

核心代码结构（总 142KB）：

src/ ├── core/ # 12KB：基础工具（xhr、dom、event） ├── chart/ # 85KB：三个图表类（LineChart、BarChart、PieChart） │ ├── line.js # 28KB：支持时间轴、多系列、area fill │ ├── bar.js # 32KB：支持堆叠、分组、负值 │ └── pie.js # 25KB：支持环形图、label 外部连接线 ├── utils/ # 18KB：SVG 工具（path generator、text wrap、color palette） ├── theme/ # 5KB：主题配置（颜色、字体、间距） └── index.js # 2KB：入口，暴露 `ERPChart.render(container, config)`

关键优化点：

SVG Path 最小化：不用d3.line()生成 path，手写path.setAttribute('d', 'M0,100 L10,95 L20,90...')，省去 d3-path 的 15KB；
Tooltip 零 JS：SVG<g>元素内嵌<title>，浏览器原生 tooltip，无 JS 开销；
字体加载兜底：不引入 Google Fonts，用系统字体栈font-family: "Segoe UI", "Microsoft YaHei", sans-serif；
错误监控精简：只捕获window.onerror和xhr.status !== 200，上报用navigator.sendBeacon()，不依赖 Sentry。

上线后，该模块在客户 200+ 台 IE11 终端上稳定运行，首屏加载时间从原来的 8.2s（旧 Flash 报表）降到 1.4s。

4.3 经验教训：在约束中定义“高级”

很多人觉得“高级”等于“功能多”“效果炫”。但在这个 ERP 场景里，“高级”是：

能活着：在 IE11、150KB、无构建工具的地狱里，跑起来；
能维护：代码全部 ES5，注释详尽，新人三天能上手改 bug；
能演进：预留了chart.registerPlugin()接口，未来可插拔式加入新图表，不破坏现有结构。

真正的高级，是让技术隐形，让用户只看到结果。当你在 PPT 里放一个“支持 IE11 的现代化可视化模块”时，客户眼里看到的，不是代码，而是“你们真能搞定我们这摊烂事”。

5. 科研级脑电波形分析：WebAssembly 加速数学计算的实战边界

这是另一个极端场景：用 Web 技术做 MNE-Python 同等能力的脑电 ERP（Event-Related Potential）分析。用户上传.edf文件（通常 200MB+），前端需实时：

解析 EDF 头信息；
读取原始信号（256 通道 × 1000Hz × 10 分钟 = 1.5 亿样本点）；
执行滤波（Butterworth 5 阶低通）、重参考（average reference）、分段（epoching）、基线校正、平均叠加；
渲染高精度波形图（支持毫秒级缩放、通道叠加、峰值标记）。

传统方案是 Python + Jupyter + MNE，但客户要求 Web 端，理由是：研究人员在医院现场，只有 iPad，无法装 Anaconda。

5.1 为什么 JavaScript 数学计算是瓶颈？

JavaScript 的 Number 是 IEEE 754 双精度浮点，计算精度足够，但性能是硬伤。实测：对 100 万点数组做 Butterworth 滤波（scipy.signal.filtfilt的 JS 移植版），Chrome 需 4.2 秒；而 Python 的 NumPy，在同样机器上仅需 0.18 秒——相差 23 倍。

根源在于：

JS 引擎对数组运算无 SIMD 优化；
每个数字都是对象，内存布局不连续；
无原生复数支持，FFT 需手写 complex 类，开销巨大。

所以，必须引入 WebAssembly（Wasm）——它能编译 C/C++/Rust 代码，在浏览器里接近原生速度运行。

5.2 Wasm 方案选型：Rust vs C vs AssemblyScript

我对比了三种主流 Wasm 编译路径：

方案	编译体积	开发效率	数学库支持	IE11 兼容	实测 100 万点滤波耗时
Rust + ndarray-wasm	180KB	⭐⭐⭐⭐	丰富（nalgebra, ndarray）	❌（需 polyfill）	0.21s
C + FFTW + Emscripten	220KB	⭐⭐	极佳（FFTW 专业 FFT）	✅（emrun 支持）	0.19s
AssemblyScript	95KB	⭐⭐⭐	弱（需手写 FFT）	✅	0.33s

最终选择 C + FFTW，理由：

FFTW 是业界标准，其fftw_plan_dft_r2c_1d()对实数 FFT 优化到极致，比 Rust 的rustfft快 12%；
Emscripten 支持 IE11，通过--minify-level 0 --memory-init-file off生成兼容代码；
C 生态成熟，libdspl（数字信号处理库）可直接移植，无需重复造轮子。

5.3 关键集成：如何让 Wasm 与 Web 图表协同？

Wasm 不是银弹。它解决了计算，但带来了新问题：

内存管理：Wasm Module 的线性内存（Linear Memory）与 JS Heap 隔离，数据传递需Module.HEAPF32.set()，拷贝开销大；
异步阻塞：Wasm 计算是同步的，若在主线程执行，UI 会冻结；
图表渲染压力：计算完的 1.5 亿点，不可能全渲染，需智能采样。

我的分层架构：

Wasm 层（C）：只做纯计算。输入：float32*指针（指向 JS 传入的 ArrayBuffer）；输出：float32*指针（指向结果 Buffer）。不碰 DOM，不碰网络。
JS Bridge 层：用Web Worker加载 Wasm Module，避免阻塞主线程。Worker 接收ArrayBuffer，调用wasmModule.filter(dataPtr, len, cutoffFreq)，返回结果 `Array