wasm在矩阵运算中比js快，因其接近原生执行、支持simd及高效内存访问；但小矩阵（如100×100）因js的v8内联优化和typedarray优势更轻量，且wasm存在初始化阻塞、数据拷贝开销及调用成本等瓶颈。
为什么 wasm 在矩阵运算中比 JS 快，但不是所有矩阵都适合搬过去
WebAssembly 对高维矩阵运算的加速效果取决于规模与调用模式。实测表明：1000×1000 以上的浮点矩阵乘法，wasm 才稳定快于 JavaScript；而 100×100 级别时，JS 的 V8 内联优化 + TypedArray 原生访问反而更轻量。
关键瓶颈不在计算本身，而在数据进出 wasm 内存的开销：
- 每次传入
new Float32Array(input)都触发内存拷贝和 GC 压力 - wasm 模块首次加载 +
WebAssembly.instantiate()同步阻塞主线程，若在用户点击后才初始化，会明显卡顿 - 小矩阵单次调用，wasm 的启动、边界跳转、栈帧建立成本可能超过收益
必须用 initSync() 初始化 wasm 模块，且提前加载
使用 wasm-pack build --target web 生成的 Rust 绑定，默认导出的是异步 init()，但它底层仍依赖同步 fetch 和编译，首次调用时会阻塞渲染线程——这不是“异步友好”，而是“伪异步”。
正确做法是改用 initSync()，并配合 type="module" 脚本在页面解析阶段就完成初始化：
import init, { initSync, matmul } from './pkg/matrix_wasm.js';
<p>// ✅ 正确：模块加载即初始化，不卡首帧
initSync();</p><p>// ❌ 错误：await init() 可能导致白屏或输入延迟
// await init();</p>
若因模块过大必须异步，应在 requestIdleCallback 中调用 init()，而非绑定到按钮点击或输入事件上。
内存复用比算法优化更重要
前端 wasm 推理中最常被忽略的性能杀手，是反复创建视图对象。每次执行 new Float32Array(instance.exports.memory.buffer) 不仅分配新视图，还会让旧视图滞留等待 GC，在动画帧循环中极易引发抖动。
应固定内存布局，并复用视图：
- 在 Rust 中预分配 input/output buffer offset，例如 input 从
0x0开始，output 从0x100000开始 - JS 层初始化后保存
const inputView = new Float32Array(memory.buffer)，后续只调用inputView.set(newData) - 避免在循环中 new ArrayBuffer 或重新 bind view；清空策略优先用
inputView.fill(0)而非重建
Rust 层需禁用 panic、启用 SIMD 并对齐内存
浏览器 wasm 运行时无法处理未捕获 panic，一旦触发就会终止整个模块。Rust 侧必须显式关闭 panic 机制：
[profile.release] panic = "abort" # 替代默认的 "unwind"
同时，开启 SIMD 支持可让矩阵乘法获得 2–4 倍吞吐提升（尤其在 f32x4 向量加/乘场景）：
- 编译时加
--features=stdsimd和-C target-cpu=native - 内存分配需按 64 字节对齐以适配 AVX/SSE 指令，例如用
std::alloc::alloc手动申请对齐 buffer - 避免在 hot path 中使用
Vec::push或动态扩容；全部预分配、静态切片访问
这些细节不写进 Rust 代码里，JS 层再怎么优化调用也白搭——wasm 的性能天花板，是由 Rust 编译器和内存模型共同决定的，不是靠 JS 调用次数堆出来的。
