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

Extension.js 为你启用了什么
Wasm 插件会配置:experiments.asyncWebAssembly = true- 在模块解析的扩展名中加入
.wasm - 为常用 Wasm 库设置路径别名(例如用于媒体处理的 ffmpeg、用于图像处理的 imagemagick、用于 OCR 的 tesseract),让导入在运行时能正确解析。
把 .wasm 文件作为资源打包
直接 import 一个 .wasm 文件会把它实例化为异步 WebAssembly 模块,这正是 wasm-bindgen 和 wasm-pack 产物所期望的。有些库则附带 Emscripten 加载器,其 init() 需要文件的 URL 或字节。对于这类库,加上 ?url:构建会把二进制文件复制到 assets/ 并把它的 URL 交给你的代码,不需要改动 extension.config.js。
?url 约定完全一致。
只有在加载器接受任意协议时才把 URL 直接交给它。有些运行时只接受 http: 和 https:,遇到 chrome-extension: URL 就会抛错,@imagemagick/magick-wasm 就是其中之一:它的 initializeImageMagick 会以 “Only http/https protocol is supported” 失败。对于这类库,按上面的方式自行 fetch 构建产物并把字节交给它:initializeImageMagick(new Uint8Array(bytes))。
用法
把 Wasm 模块作为常规开发/构建流程的一部分使用:典型使用场景
- 计算密集型的解析/变换。
- 媒体处理管线。
- OCR / 图像处理工作流。
- 在 web/运行时上下文之间共享的、对性能敏感的算法。
最佳实践
- 让 Wasm 模块专注于热点路径,把编排逻辑保留在 JavaScript/TypeScript 里。
- 对扩展上下文(background、content script、页面)验证产物体积和加载时机。
- 在你所发布的目标浏览器上测试 Wasm 密集型流程(
chrome、edge、firefox)。
下一步
- 进一步了解 WebAssembly。
- 了解 Extension.js 如何处理 ECMAScript 模块。

