1. 为什么“主流 Web 高级数据可视化库”这个评测本身就是一个高风险动作我第一次接到“全评测全球主流 Web 高级数据可视化与分析库”这个需求时心里其实是发怵的——不是因为技术难度而是因为这个命题天然带着三个致命陷阱而市面上90%的所谓“横向对比”文章恰恰就栽在这三处。第一个陷阱把“能画图”等同于“能做分析”。Highcharts、ECharts、Chart.js 这些名字你肯定听过它们确实能渲染漂亮的折线图、饼图、热力图但如果你真拿它们去跑一个用户行为漏斗分析、做实时流式数据的异常检测、或者对接一个需要动态下钻到千万级明细的 OLAP 查询引擎你会发现它们连基础的数据预处理管道都得靠你自己手撸。真正的“高级分析能力”从来不是画布上那几根线条的事而是背后整套数据流编排、计算卸载、状态管理、交互语义建模的能力。比如当你要在一张散点图上点击某个异常点触发后端发起一个带时间窗口和维度过滤的聚合查询并把结果以小倍数图small multiples形式叠加在原图右下角——这个动作里前端库只负责“点击”和“渲染”中间所有逻辑链路才是决定项目成败的关键。第二个陷阱用静态截图代替真实场景压测。太多评测文章喜欢放四张并排的柱状图截图标上“渲染性能对比10万条数据”然后写一句“ECharts 耗时 320msHighcharts 耗时 410ms”。这毫无意义。真实业务里你面对的从来不是“一次性加载10万条静态 JSON”而是用户拖拽时间轴每秒触发3次增量查询图表区域被缩放到 200% 后重新渲染同时有5个联动视图在响应同一个筛选器变更浏览器内存占用已超 800MBGC 频繁触发……这些场景下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-A53512MB 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✅canvasrenderer⚠️需手动setOption更新无原生 Mapbox layer1.8s320MB42fps850ms需重绘整个图表轨迹线为新图表与主图坐标系不一致需手动同步缩放Highcharts❌仅 SVG / VML❌无 Mapbox 支持——OOM 崩溃——————50 万点直接触发浏览器内存警告强制终止Chart.js✅canvasbackend❌无地理坐标支持2.3s410MB38fps1200ms重绘开销大无地理投影能力经纬度被当普通 XY 坐标严重失真Plotly.js✅webgl/svgcanvas需 hack⚠️mapboxtrace 类型但仅支持基础 marker3.1s580MB35fps950msmapboxtrace 不支持自定义 marker 图标如电池图标且无法响应 click 事件获取原始数据索引D3.js✅完全可控✅d3-geomapbox-gl-js官方示例1.2s85MB58fps210ms仅重绘轨迹线需手写全部逻辑无开箱即用的轨迹动画、缩放适配Apache ECharts GL✅WebGL 渲染✅官方echarts-glmapbox-gl-js插件0.9s120MB62fps330msscatter3D在 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是维度categoricalrevenue是度量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-reactcubejs-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 文件总大小 ≤ 150KBgzip 后兼容 IE11是的IE11所有请求必须带X-ERP-Auth-Tokenheader不能引入任何第三方 CDN所有资源走 ERP 内网域名。这不是技术选型这是考古发掘。你得在废墟里用捡来的砖头盖一座能用的房子。4.1 为什么主流库全军覆没先看数据ECharts完整版 1.2MB精简版tree-shaking仍 420KBIE11 需额外core-jspolyfill180KBChart.js3.9.1 版本 120KB但依赖moment.js30KB处理时间且 IE11 下Promise、fetch需 polyfill65KB超限Highcharts官方声称“支持 IE11”但其highcharts.js本身 380KB且必须搭配highcharts-more.js80KB才能用热力图Plotly.js最小 bundle 520KB且依赖webglIE11 不支持D3.js v7核心模块 110KB但d3-array、d3-scale、d3-axis等常用模块加起来 280KBLightweight 替代品如 uPlotuPlot 本身仅 12KB但无地理、无时间轴、无主题定制需自己补全。所有“现代”库都在这个场景下跪了。它们的设计哲学是“功能完备”而 ERP 嵌入的需求是“极致精简”。4.2 我的“考古级”方案Vanilla JS SVG 手写 Service Worker 缓存既然库不行那就回归本质用原生 API只实现必需功能。目标一个能显示折线图、柱状图、饼图的报表模块支持基本交互hover tooltip、click drilldownJS 总大小 ≤ 148KB。技术栈选择逻辑渲染引擎SVG不是 Canvas。理由IE11 原生支持 SVG且 SVG 元素自带title标签hover tooltip 一行代码搞定titleRevenue: $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 WorkerIE11 不支持没关系用localStoragefallback。SW 用于缓存图表配置 JSONIE11 用localStorage.setItem(chartConfig, JSON.stringify(config))。核心代码结构总 142KBsrc/ ├── core/ # 12KB基础工具xhr、dom、event ├── chart/ # 85KB三个图表类LineChart、BarChart、PieChart │ ├── line.js # 28KB支持时间轴、多系列、area fill │ ├── bar.js # 32KB支持堆叠、分组、负值 │ └── pie.js # 25KB支持环形图、label 外部连接线 ├── utils/ # 18KBSVG 工具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 的 15KBTooltip 零 JSSVGg元素内嵌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 同等能力的脑电 ERPEvent-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 类开销巨大。所以必须引入 WebAssemblyWasm——它能编译 C/C/Rust 代码在浏览器里接近原生速度运行。5.2 Wasm 方案选型Rust vs C vs AssemblyScript我对比了三种主流 Wasm 编译路径方案编译体积开发效率数学库支持IE11 兼容实测 100 万点滤波耗时Rust ndarray-wasm180KB⭐⭐⭐⭐丰富nalgebra, ndarray❌需 polyfill0.21sC FFTW Emscripten220KB⭐⭐极佳FFTW 专业 FFT✅emrun 支持0.19sAssemblyScript95KB⭐⭐⭐弱需手写 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