WebAssembly 和 JavaScript 如何高效互操作？

WebAssembly 和 JavaScript 的互操作，核心不是“谁调用谁”，而是把边界设计清楚：JS 负责 DOM、网络、事件和业务编排，Wasm 负责计算密集、可复用、对性能敏感的逻辑。两边通过 import/export 交换函数，通过线性内存交换数据。最常见的写法是 JS 加载 Wasm，并把宿主函数注入进去。这样 Wasm 里可以调用日志、时间、随机数等浏览器能力，DOM API 仍然是 JS 的主场。

javascript
const imports = {
  env: {
    log_i32: (v) => console.log('wasm:', v),
    now: () => performance.now()
  }
};

const { instance } = await WebAssembly.instantiateStreaming(
  fetch('/calc.wasm'),
  imports
);

console.log(instance.exports.add(10, 32));

如果服务端没有正确设置 application/wasm，instantiateStreaming 会失败，项目里要准备降级路径，尤其是 CDN 或本地静态服务器配置不全时。

javascript
async function loadWasm(url, imports) {
  const res = await fetch(url);
  if (WebAssembly.instantiateStreaming && res.headers.get('content-type') === 'application/wasm') {
    return WebAssembly.instantiateStreaming(res, imports);
  }
  return WebAssembly.instantiate(await res.arrayBuffer(), imports);
}

追问

WebAssembly 能不能直接传 JavaScript 对象？

多数稳定场景下不能把普通 JS 对象“原样”传进 Wasm 函数，Wasm 基础类型主要是 i32、i64、f32、f64，复杂对象通常要拆成指针、长度或句柄。externref 和 GC 相关能力正在改善对象引用问题，但工具链支持并不完全一致。工程上更稳的是让 JS 保管对象，Wasm 只拿整数句柄，需要时再回调 JS 查询。取舍在于：句柄方案多一层映射，但兼容性和可控性更好。

字符串和数组应该怎么传，哪里最容易踩坑？

字符串一般要编码成 UTF-8 写入 Wasm 线性内存，然后把指针和长度传给导出函数；数组也类似，用 TypedArray 把数据拷进 memory.buffer。坑在于 memory.grow() 后，旧的 Uint8Array 视图会指向失效的 ArrayBuffer，继续写可能看起来没报错但数据已经不对。另一个边界是大对象频繁来回拷贝会吞掉性能收益。能批量传就批量传，能让 Wasm 连续处理就不要反复跨边界。

javascript
const memory = instance.exports.memory;
let bytes = new Uint8Array(memory.buffer);
const text = new TextEncoder().encode('hello wasm');
const ptr = instance.exports.alloc(text.length);
bytes.set(text, ptr);
instance.exports.process_text(ptr, text.length);

i64、BigInt 和 Number 混用有什么限制？

Wasm 的 i64 在 JS 侧对应 BigInt，而不是 Number，这一点经常让接口在运行时炸掉。instance.exports.sum64(1n, 2n) 可以，但传 1 会触发类型错误；BigInt 也不能直接和 Number 做加法。边界设计时要明确哪些值可能超过 53 位安全整数，像文件偏移、哈希值更适合 BigInt。取舍是 BigInt 更准确，但 JSON 序列化和老代码兼容都要额外处理。

JS 调 Wasm 一定比纯 JS 快吗？

不一定。Wasm 的优势在循环密集、数值计算、编解码这类任务；如果只是调用一个小函数，然后马上回 JS 更新 DOM，跨边界成本可能比计算本身还高。实际优化时应先用 Performance 面板确认热点，而不是看到 Wasm 就迁移。实用原则是把连续计算放进 Wasm，一次传入输入，一次拿回结果。不要在循环里成千上万次 JS/Wasm 互调。

多线程和共享内存能直接用于互操作吗？

可以，但前提更苛刻。浏览器里使用 Wasm 线程通常依赖 SharedArrayBuffer，需要跨源隔离头：Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp。这个配置会影响第三方资源加载，广告、统计脚本、跨域图片都可能被拦住。边界上要先确认业务能接受这些限制，再决定是否引入共享内存。

WebAssembly 和 JavaScript 互操作最稳的思路是少跨边界、批量传数据、明确所有权。JS 做宿主，Wasm 做计算核心，内存、类型和异常都提前约定好，性能收益才不会被胶水代码抵消。