WebAssembly 在浏览器端的落地边界与性能真相

Wasm 常被宣传为"让前端跑出原生性能"。真实项目做下来，结论要收敛得多：Wasm 在计算密集、数据形状简单的场景确实有数倍收益；一旦涉及频繁跨边界传字符串或 DOM 操作，性能反而可能倒退。本文给出判断依据与实测方法。

一、什么时候真的该用 Wasm

适合：图像/音视频编解码、加解密、正则与编译类工具、物理与几何计算、游戏循环。特征是单次调用输入小、循环次数多、不做 IO。

不适合：表单校验、路由、状态管理、任何需要频繁读写 DOM 的逻辑。原因是 JS 与 Wasm 之间每次跨边界调用都有编组成本，而 Wasm 沙箱无法直接访问 DOM。

一个可靠的经验法则：如果函数内部的循环次数低于一万次，Wasm 的调用编组开销很可能会吃掉收益。

二、Rust 最小吃货示例

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn sha_like_mix(mut seed: u64) -> u64 {
    for _ in 0..1_000_000 {
        seed ^= seed << 13;
        seed ^= seed >> 7;
        seed ^= seed << 17;
    }
    seed
}

构建：

cargo build --release --target wasm32-unknown-unknown
wasm-bindgen target/wasm32-unknown-unknown/release/mix.wasm \
  --out-dir pkg --target web

前端加载：

import init, { sha_like_mix } from "./pkg/mix.js";
await init();
const t0 = performance.now();
const r = sha_like_mix(42);
console.log(r, performance.now() - t0);

三、跨边界传数据的三种模式

模式一：拷贝字节（最通用）

use js_sys::Uint8Array;

#[wasm_bindgen]
pub fn transform(input: &[u8]) -> Vec<u8> {
    input.iter().map(|b| b ^ 0x5a).collect()
}

&[u8] 会被复制进 Wasm 线性内存，返回值再复制出来。适合输入规模小于几百 KB 的一次性处理。

模式二：共享内存（大数据流式处理）

把大块数据放进导出的 WebAssembly.Memory，JS 用 new Uint8Array(wasm.memory.buffer) 直接读，避免拷贝。

const mem = instance.exports.memory;
const out = new Uint8Array(mem.buffer, ptr, len);   // 零拷贝视图
const blob = new Blob([out], { type: "image/png" });

注意：一旦 Wasm 内部再分配导致内存 grow，所有旧的 typed array 视图会失效，必须重新构造。

模式三：字符串的代价

&str 跨边界要经历 UTF-8 编码校验与两次拷贝。在循环里反复传字符串是 Wasm 头号性能陷阱。正确做法是批量传：一次性把整个文本传进去处理完再返回。

四、性能真相：基准测试方法

跨边界成本必须实测，不能靠猜。标准做法是分别跑纯 JS 实现与 Wasm 实现，并区分"单次大调用"与"多次小调用"。

function bench(label, fn, iters) {
  fn();                                   // warm up
  const t0 = performance.now();
  for (let i = 0; i < iters; i++) fn();
  console.log(label, ((performance.now() - t0) / iters).toFixed(3), "ms/op");
}

const N = 1 << 16;
bench("js  one call", () => jsMix(42, N), 20);
bench("wasm one call", () => wasm_mix(42), 20);
bench("wasm 20x calls", () => { for (let i = 0; i < 20; i++) wasm_mix(42 << i); }, 20);

典型结果：单次百万次循环 Wasm 快 3~6 倍；把同样的工作量切成 20 次小调用，差距缩到 1.5 倍以内；若在循环里传字符串，JS 版本反而更快。

五、体积与加载体验

一个 Rust hello world 产物约 1.5KB gzip，带 String/Vec 后轻松到 40~120KB。优化清单：

[profile.release]
opt-level = "s"
lto = true
codegen-units = 1
panic = "abort"
strip = true

再配 wasm-opt -Oz。加载体验上务必流式加载 + 骨架占位，别让用户在空白页等 300ms 以上的模块下载与编译。

const res = await fetch("/pkg/mix_bg.wasm");
if (!res.ok) { /* 回退到 JS 实现 */ }
const mod = await WebAssembly.compileStreaming(res);

保留一份纯 JS 回退路径很重要：老浏览器、内存受限环境、以及产物加载失败时，功能可用性优先于性能。

六、别忘了线程与流式编译

计算密集型任务放主线程会掉帧。两种解法：

• SharedArrayBuffer + Wasm 线程（需要 COOP/COEP 响应头）；
• 把 Wasm 放进 Web Worker，消息协议自己定。

大产物用 WebAssembly.instantiateStreaming 边下载边编译，比 arrayBuffer 方式省一次全量解析。

小结

Wasm 的正确定位是"浏览器里的计算内核"，不是"前端新语言"。选型时用两个问题筛：循环次数是否足够多、跨边界数据能否批量且为字节。两者皆是才上 Wasm，并且一定保留 JS 回退、一定实测小调用场景的编组开销。按这套边界用，它能带来真实的性能收益；越界使用，它只会带来体积、复杂度和更慢的用户体验。