17370845950

WebAssembly 不会取代 JavaScript，二者是协作关系；Wasm 无 DOM 访问能力，纯计算任务更高效，JS 负责 I/O 和 UI；调用需通过 instantiateStreaming 加载并检查导出函数，注意内存泄漏。

WebAssembly 不会取代 JavaScript，它俩是搭档，不是对手。 你写一个图像滤镜功能，用 JavaScript 做 UI 控制和按钮响应，用 WebAssembly 处理像素计算——这才是真实项目里最常见、最合理的分工。

为什么不能直接用 WebAssembly 操作 DOM？

WebAssembly 标准本身不提供任何浏览器 API 访问能力，document.getElementById、addEventListener、fetch 这些全不可用。它运行在沙箱中，只能访问自己线性内存（WebAssembly.Memory）和通过 JavaScript 显式传入的函数。

• 试图在 Wasm 里直接调 DOM → 浏览器报错：ReferenceError: document is not defined
• 所有 DOM 更新必须由 JavaScript 主导，Wasm 只负责“算完把结果交出来”
• 哪怕你用 Rust + wasm-bindgen，生成的 JS 胶水代码也绕不开 document 调用

什么时候该把代码从 JavaScript 搬到 WebAssembly？

看这三点：是否纯计算、是否反复执行、是否已有成熟 C/Rust/Go 实现。比如：

• 实时音视频编解码（ffmpeg.wasm）→ 合适；简单表单校验 → 不合适
• 游戏物理引擎（Box2D 编译为 Wasm）→ 合适；点击弹个 alert → 绝对不合适
• 你团队已有一套 C++ 图像处理库 → 编译成 .wasm 省事；新写一个排序函数 → JS 的 Array.prototype.sort 更快更稳

性能差异不是玄学：同个矩阵乘法，在 Chrome 中 JavaScript 耗时约 120ms，Wasm 耗时约 35ms，但 Wasm 加载+编译首次开销多出 ~15–30ms。高频小任务反而更慢。

立即学习“Java免费学习笔记（深入）”；

怎么安全地在 JS 里调用 Wasm 函数？

别手写 base64 字节码（如 "AGFzbQEAAAABBwFgAn9/AX8DAgEABwcBA2FkZAAACgkBBwAgACABags="），那只是 demo 玩意儿。生产环境请走标准流程：

• 用 rustc --target wasm32-unknown-unknown 或 emcc 编译源码，输出 .wasm 文件
• 用 WebAssembly.instantiateStreaming 加载（支持流式解析，比 instantiate 快）
• 导出函数参数必须是基本类型（i32/f64），字符串/数组需手动管理内存布局
• 务必检查 instance.exports 是否包含预期函数名，否则运行时报 TypeError: instance.exports.xxx is not a function

(async () => {
  try {
    const response = await fetch('math_utils.wasm');
    const { instance } = await WebAssembly.instantiateStreaming(response);
    const result = instance.exports.add(100, 200); // ✅ 正确调用
    console.log(result); // 300
  } catch (err) {
    console.error('Wasm load failed:', err.message); // ❌ 避免静默失败
  }
})();

最容易被忽略的一点：Wasm 模块一旦加载，就固定在内存里，不会自动 GC。如果你动态加载多个模块又不用了，得手动释放 WebAssembly.Module 和 WebAssembly.Instance 引用，否则内存泄漏比 JS 更隐蔽。