webassembly 默认单线程，多线程需宿主支持（如web workers）或启用未默认开放的threads提案；simd可加速向量化运算，内存复用与合理布局才是报表性能关键。
WebAssembly 本身不提供并行模型——WebAssembly 是单线程执行的，所有并行能力必须依赖宿主环境（如 JavaScript 的 Web Workers）或底层运行时（如 oneTBB、Rayon）在 wasm 模块内部实现线程调度。浏览器中真正能跑多线程 wasm 的唯一合规路径是启用 threads 提案，但截至 2026 年 4 月，Chrome、Firefox、Edge 均**默认禁用**该功能，需用户手动开启实验性标志，生产环境不可用。
为什么不能直接用 WebAssembly.parallel_for
oneTBB 的 parallel_for、parallel_reduce 等 API 在 wasm 中无法“开箱即用”：它们底层依赖 POSIX 线程（pthreads）或 Windows 线程 API，而标准 wasm 模块没有操作系统调用能力。即使你用 Rust + rayon 编译出带线程的 wasm，浏览器加载时会直接报错：LinkError: import object field 'pthread_create' is not a Function。这不是配置问题，是规范限制。
可行的并行加速路径只有两条
实际落地报表计算加速，必须绕过 wasm 自身线程限制，分层设计：
- 用
Web Workers启动多个 wasm 实例，每个 worker 承担数据子集（如按时间分区、按维度分片），worker 内部用纯单线程 wasm 处理；前端用Promise.all()聚合结果 - 在 wasm 模块内启用
WebAssembly SIMD指令（非线程，但单指令多数据），对向量化操作（如列求和、条件过滤、浮点批量转换）提速 3–5 倍；需确认目标浏览器支持（Chrome 91+、Firefox 89+、Edge 91+） - 若报表逻辑含大量分支判断或状态累积（如漏斗转化率、滚动窗口统计），SIMD 无效，此时必须靠 worker 分片 + wasm 单线程极致优化（例如用 Rust 手写 cache-friendly 的遍历顺序，避免
Vec::push动态扩容）
前端调用时最容易忽略的内存陷阱
报表数据量大（如百万行 × 20 列），频繁 copyTo 到 wasm 内存会拖垮性能：
- 不要每次计算都
new Uint8Array(wasmModule.memory.buffer)—— 这触发 GC，且 buffer 可能被 realloc 导致指针失效 - 初始化后固定分配一块足够大的
WebAssembly.Memory（如new WebAssembly.Memory({ initial: 256, maximum: 1024 })），所有后续计算复用同一块内存视图 - 用
Uint32Array或Float64Array直接映射 wasm 导出的内存偏移（如const dataView = new Float64Array(wasmModule.memory.buffer, offset, length)），避免中间拷贝 - Rust 侧导出函数参数只能是
i32（内存地址偏移），前端传入前必须确保数据已写入 wasm 内存对应位置，否则读到的是未初始化垃圾值
真正卡住报表加速的往往不是算法本身，而是内存布局和跨边界数据搬运——把 100 万行数字从 JS Array 搬进 wasm 内存的时间，可能比 wasm 里算完还长。先压测搬运耗时，再谈计算优化。
