Skip to main content
无需自定义打包配置,即可在扩展中使用 WebAssembly。 Extension.js 在其 Rspack 管线中带有内置的 WebAssembly(Wasm)默认设置,因此常见的 Wasm 工作流无需额外配置即可工作。

什么场景适合用 WebAssembly

  • 你在扩展中运行计算密集型任务(解析、媒体、光学字符识别(OCR)、变换)。
  • 你需要让常用代码路径达到接近原生的性能。
  • 你要复用来自 web 项目的现有 Wasm 模块。

WebAssembly 的能力

模板示例

transformers-js

transformers-js template screenshot 使用 Transformers.js 的 AI/ML sidebar 扩展,底层通过 WebAssembly 做推理。
仓库:extension-js/examples/transformers-js

Extension.js 为你启用了什么

Wasm 插件会配置:
  • experiments.asyncWebAssembly = true
  • 在模块解析的扩展名中加入 .wasm
  • 为常用 Wasm 库设置路径别名(例如用于媒体处理的 ffmpeg、用于图像处理的 imagemagick、用于 OCR 的 tesseract),让导入在运行时能正确解析。
这减少了从扩展脚本/页面里导入 Wasm 模块时的样板代码。

把 .wasm 文件作为资源打包

直接 import 一个 .wasm 文件会把它实例化为异步 WebAssembly 模块,这正是 wasm-bindgen 和 wasm-pack 产物所期望的。有些库则附带 Emscripten 加载器,其 init() 需要文件的 URL 或字节。对于这类库,加上 ?url:构建会把二进制文件复制到 assets/ 并把它的 URL 交给你的代码,不需要改动 extension.config.js。
这个 URL 在扩展的每个上下文中都能解析,包括页面和 service worker。它与构建为图片、字体和样式表提供的 ?url 约定完全一致。 只有在加载器接受任意协议时才把 URL 直接交给它。有些运行时只接受 http: 和 https:,遇到 chrome-extension: URL 就会抛错,@imagemagick/magick-wasm 就是其中之一:它的 initializeImageMagick 会以 “Only http/https protocol is supported” 失败。对于这类库,按上面的方式自行 fetch 构建产物并把字节交给它:initializeImageMagick(new Uint8Array(bytes))。

用法

把 Wasm 模块作为常规开发/构建流程的一部分使用:
你也可以用一个公开可用的 Wasm 示例进行测试:

典型使用场景

  • 计算密集型的解析/变换。
  • 媒体处理管线。
  • OCR / 图像处理工作流。
  • 在 web/运行时上下文之间共享的、对性能敏感的算法。

最佳实践

  • 让 Wasm 模块专注于热点路径,把编排逻辑保留在 JavaScript/TypeScript 里。
  • 对扩展上下文(background、content script、页面)验证产物体积和加载时机。
  • 在你所发布的目标浏览器上测试 Wasm 密集型流程(chrome、edge、firefox)。

下一步

视频讲解