WebAssembly替代JavaScript执行高强度逻辑运算，需在Worker中异步加载预编译模块、用SharedArrayBuffer共享内存、禁用结构化克隆、开启Rust高级优化及SIMD，并严格做内存边界检查。
直接上结论：把高强度逻辑运算从 JavaScript 搬到 WebAssembly，不是“优化 JS”，而是换执行引擎——用预编译的、静态类型的、可控内存的线性指令替代动态解释+GC 的 JS 引擎路径。
这背后的关键不是“更快一点”，而是规避 JS 运行时不可控抖动、避免大数组拷贝、绕过单线程阻塞。下面分场景说清楚怎么做、为什么、以及最容易栽跟头的地方。
WebAssembly 实例必须在 Worker 中运行，否则白搭
主线程跑 WebAssembly.instantiate() + 调用计算函数，哪怕函数本身很快，也会卡住 UI 帧（尤其在低端设备上）。这不是理论风险，是实测必现的掉帧源。
- Worker 内加载：用
fetch()+WebAssembly.instantiateStreaming()异步完成，不能用importScripts()同步加载（会阻塞 Worker 启动） - Wasm 模块需提前编译好（如 Rust 用
wasm-pack build --target web），不建议在 Worker 里动态 fetch + compile 字节码（WebAssembly.compile()开销大且无缓存） - 实例化后缓存
instance.exports和instance.exports.memory，避免每次调用都重新查表
传参和取结果必须绕开结构化克隆
JS 调用 Wasm 函数时，若传入一个 Float32Array，默认行为是深拷贝整个数组到 Wasm 线性内存——10MB 数组 = 10MB 拷贝延迟。这是性能杀手，也是新手最常踩的坑。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：主线程分配
SharedArrayBuffer，用postMessage(buffer, [buffer])传给 Worker；Worker 用它构造WebAssembly.Memory或直接映射为Float32Array - Wasm 函数签名应设计为接受指针偏移（
i32）和长度（i32），而非完整数组 - 小结果（如标量、短状态码）用
postMessage({result: 42})；大结果（如计算完的矩阵）不传数据，只发{offset: 16384, length: 1000000}，主线程从共享内存读
Rust 编译时必须开关键优化开关，否则性能打五折
默认 cargo build --release 生成的 wasm 并不等于“高性能”——它没开 SIMD、没关调试符号、没启用 LTO，实际执行效率可能只比 JS 快 1.2 倍，而不是宣称的 3–5 倍。
- 在
Cargo.toml中加：[profile.release] lto = true; codegen-units = 1; panic = "abort" - 用
wasm-pack build --release --target web -d pkg构建，再手动跑wasm-opt -Oz pkg/*.wasm -o optimized.wasm（来自 Binaryen 工具链）进一步压体积和指令数 - 需要并行计算时，加编译参数：
RUSTFLAGS="-C target-feature=+simd128" cargo build --release，并在 Wasm 模块中显式用#[cfg(target_feature = "simd128")]分支
内存越界访问不会报 SyntaxError，而是在运行时静默崩溃
Wasm 函数里写 ptr[i] = x 越界，不会像 JS 那样抛 RangeError，而是触发 RuntimeError: memory access out of bounds，且这个错误只在 Worker 内部可见，主线程完全收不到——你只会看到计算没返回、UI 卡住、控制台空空如也。
- 所有数组访问必须做边界检查：用
slice.get_unchecked(i)前先确认i - Worker 中所有 Wasm 调用必须包在
try { ... } catch (e) { console.error(e) }里，且重点捕获RuntimeError - 开发期开启 Emscripten 的
-s SAFE_HEAP=1或 Rust 的bounds-checking（仅 debug），上线前关掉，但保留校验逻辑
真正难的从来不是“怎么让 Wasm 跑起来”，而是怎么让 JS 和 Wasm 在共享内存里不打架、不越界、不漏错、不重复拷贝——这些细节不抠清楚，性能提升就永远停留在 demo 层面。
