WebAssembly 如何做模块化和动态加载才稳？

为什么 WebAssembly 需要模块化？

小 demo 里一个 .wasm 文件就够了，但真实应用会遇到包体、团队协作、功能隔离和灰度发布问题。图像处理、规则计算、渲染、加密这些能力如果全部塞进一个模块，用户打开页面就要下载完整二进制，哪怕只用其中一个功能。模块化的目标是把“必须立即可用”的部分和“用到再加载”的部分拆开。

拆模块不是越细越好。每个模块都有加载、编译、实例化和接口维护成本，模块之间还可能复制数据。比较实用的边界是按业务能力或稳定性拆：基础工具模块长期缓存，重计算模块按需加载，实验功能单独版本化。

动态加载应该怎么写？

优先使用 instantiateStreaming，它可以边下载边编译。生产环境还要准备降级路径，因为 MIME 类型、CDN 压缩、老浏览器都会让流式编译失败。

javascript
const moduleCache = new Map();

export async function loadWasmModule(name, imports = {}) {
  if (moduleCache.has(name)) return moduleCache.get(name);

  const url = `/wasm/${name}.wasm`;
  const promise = (async () => {
    try {
      return await WebAssembly.instantiateStreaming(fetch(url), imports);
    } catch (err) {
      const res = await fetch(url);
      const bytes = await res.arrayBuffer();
      return WebAssembly.instantiate(bytes, imports);
    }
  })();

  moduleCache.set(name, promise);
  return promise;
}

缓存 promise 而不是只缓存实例，是为了避免用户连续点击时触发多次加载。这里也有边界：如果模块内部有可变状态，多个调用共享同一个 instance 可能互相污染。状态敏感的模块可以缓存 WebAssembly.Module，每次创建新 instance。

多模块之间怎么通信？

最简单的方式是都由 JavaScript 调度，模块 A 输出结果，JS 整理后传给模块 B。这样可读性好，调试方便，适合大多数业务。只有当数据量很大、复制成本明显时，才考虑共享 WebAssembly.Memory。

javascript
const memory = new WebAssembly.Memory({ initial: 32, maximum: 128 });
const imports = { env: { memory } };

const [{ instance: parser }, { instance: filter }] = await Promise.all([
  loadWasmModule('parser', imports),
  loadWasmModule('filter', imports)
]);

const ptr = parser.exports.parse(inputPtr, inputLen);
const resultPtr = filter.exports.apply(ptr);

共享内存看起来优雅，但坑不少。你要约定内存布局、生命周期、字符串编码、谁负责释放内存，还要处理 memory.grow() 后 TypedArray 失效的问题。如果团队没有明确 ABI 文档，共享内存很快会变成线上事故来源。

追问

模块拆多细比较合适？

按用户路径拆通常比按源码目录拆更靠谱。首屏必需模块要小且稳定，低频功能可以延后下载。拆得太细会增加请求数和接口复杂度，拆得太粗又会拖慢首次可用时间。取舍点是“用户是否会在本次会话用到它”，而不是“代码看起来是否属于同一类”。

动态加载会影响 SEO 或首屏吗？

如果核心内容依赖 WASM 算完才显示，就会影响首屏体验，甚至影响搜索引擎抓取。内容型页面不应把正文渲染放进 WASM，WASM 更适合增强功能。对于工具页，可以先渲染 UI 和说明，再异步加载计算模块。边界是首屏可读性必须独立于 WASM，计算能力可以稍后就绪。

版本管理怎么避免新旧模块混用？

文件名带 hash 是底线，例如 image-filter.8f3a.wasm。同时要让 JS glue code 和 wasm manifest 同版本发布，不能让 CDN 单独缓存其中一个。可以在启动时校验模块导出的 ABI 版本，不匹配就拒绝运行。踩坑点是 Service Worker 缓存，如果更新策略写错，用户可能长期拿到旧 wasm。

instantiateStreaming 为什么有时会失败？

最常见原因是服务器没有返回 application/wasm。还有些 CDN 会错误处理压缩或 Range 请求，导致浏览器无法流式编译。降级到 ArrayBuffer 能提高兼容性，但会牺牲部分加载性能。上线前要用真实域名测试，而不是只在本地 dev server 里验证。

共享内存什么时候值得用？

当模块之间传递的是大块二进制数据，例如图像帧、音频 buffer、点云数据，共享内存才明显有价值。普通配置对象、短字符串、少量数字没必要为此引入复杂 ABI。共享内存还会带来释放和并发问题，尤其是多 Worker 场景。判断标准很简单：先测复制成本，如果它不是瓶颈，就别急着上共享内存。