WebAssembly · 把原生性能带进浏览器与边缘

本页定位 · WebAssembly (Wasm)

JS 再快也有天花板：图像处理、音视频编解码、加密、游戏引擎这类重计算，在浏览器里跑 JS 会很吃力。WebAssembly 让你把 C/C++/Rust 编译成一种接近机器码的中间字节码，在浏览器沙箱里近乎原生速度运行。本页讲清它是什么、和 JS 怎么配合、典型场景，以及"边缘计算"为何也爱它。我会按"是什么 → 为什么 → 怎么用 → 踩什么坑"拆开，并补上 Rust→WASM 的工具链与 WASI/组件模型——这些是它被前端和云原生同时看好的关键。作为前沿技术，它补上技术栈学院的"性能与跨语言"一角。

什么是 WebAssembly / 适用场景

Wasm · 字节码 · 沙箱 · 何时不用

一句话：WebAssembly 是一种可移植、体积小、接近原生速度的二进制指令格式。你不直接写它，而是用 Rust/C/C++/Go 写，再编译成 .wasm。它和 JS 是伙伴不是替代，跑在严格沙箱里。这一章先把它从"听过"讲到"真的懂"。

三个关键认知：字节码、伙伴、沙箱

很多初学者把 Wasm 想象成"另一种 JS"或"浏览器里的汇编语言能用文本写"。其实它更像"一种跨平台的、被设计成可安全嵌入的 CPU 指令集中间表示"。

# 一句话厘清：Wasm 不是什么
不是一种新的、给人手写的语言（你写 Rust/C）
不是用来取代 JS 的（它管不了 DOM）
不是"一定比 JS 快"的万能药（只在重计算上）
是：一种可移植、沙箱化的字节码格式

论三个关键认知

① 是字节码，不是新语言：你不直接写 Wasm，而是用 Rust/C/C++/Go 写，再编译成 .wasm。

② 是伙伴，不是替代：Wasm 负责重计算，JS 负责 DOM/生态/编排，二者通过接口互调。

③ 有沙箱：Wasm 跑在严格受限的沙箱里，不能直接碰 DOM 或系统资源，安全但需"胶水"桥接。

沙箱与安全边界：能做什么、不能做什么

Wasm 模块本身没有系统权限。它想做任何"对外界有副作用"的事（打印、读写文件、发网络请求），都必须调用宿主（浏览器/运行时）显式提供的函数。这把"不可信代码"关进了笼子。

能力	Wasm 模块默认能？	怎么做
CPU 计算	能	直接在线性内存上算
读写自己的线性内存	能	模块内部自由访问
操作 DOM	不能	经 JS 桥接调用
发起网络/文件 IO	不能	经宿主导入函数
访问操作系统	不能（除非 WASI）	服务端用 WASI 受限授权

// 宿主侧：只暴露受限导入，越权一律拒绝
const imports = {
  env: {
    log: (m) => console.log(m),   // 允许：打日志
    // 不提供 fetch / localStorage → wasm 无法越权调用
  }
};
// 模块想直接碰 DOM？没有对应导入，根本调不到

和 JS 的关系：分工而非取代

最准确的理解是"各管一摊，通过边界互调"。JS 是宿主语言，掌握 DOM、事件、生态；Wasm 是受邀来的"计算专家"，擅长密集数值运算。谁也替代不了谁——你不会用 Wasm 去写按钮点击事件，也不会用 JS 去跑一个 4K 视频的逐帧滤镜。

一个有用的心智模型：把 JS 当成"项目经理"，Wasm 当成"外包专家"。项目经理懂全局、会协调、能对接客户（DOM）；专家闷头干自己最擅长的重活。你不会让项目经理去手写底层矩阵运算，也不会让专家去直接跟客户谈需求。

所以判断"该不该用 Wasm"的第一步，永远是先问"这块是不是重计算"。是，再考虑下沉；不是，安心用 JS。把这个顺序搞反，是新人最容易犯的方向性错误。

论一个常见误解

有人听说"Wasm 比 JS 快"就打算把整个前端重写进 Wasm。这是误区：快的是"重计算"，不是"一切"。DOM 操作、事件响应这些本就是 JS 的地盘，搬进 Wasm 反而更慢（跨边界调用有开销）。正确姿势是"热点下沉"，把性能瓶颈那一块用 Wasm 重写。

适用 vs 不适用：先问"我卡在性能了吗"

Wasm 是"利器"不是"银弹"。引入它有编译、桥接、调试的额外成本，只有在 JS 真成瓶颈时才划算。

适合用 Wasm	不适合 / 没必要
图像/音视频处理、加密、物理仿真	普通的 CRUD 表单页
把既有的 C/C++/Rust 库搬上 Web	只是想少写几行 JS
游戏引擎、CAD、科学计算	简单的数据展示页
边缘/Serverless 轻量函数	强依赖大量 DOM 交互的 UI

文本格式 Wat：看清它长什么样

虽然你不直接写 Wasm，但了解它的文本表示（Wat）能帮你读懂编译产物、排查问题。下面这个函数把两个 i32 相加。

;; 文本格式 Wat：add(a, b) = a + b
(module
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add)
  (export "add" (func $add)))

别在生产手写 Wat

Wat 是给人读/调试用的，手写既易错又没收益。正常流程是用 Rust/C 写 → 编译成 .wasm，只有在排查"编译器生成的指令对不对"时才翻开 Wat。新人把时间花在工具链上，而不是背指令集。

从源码到运行：完整链路

理解"一段 Rust 怎么变成浏览器里跑的函数"，能帮你定位每一步可能出的问题。链路是：源码 → 前端编译器 → .wasm 字节码 → 引擎编译成机器码 → 实例化 → 被 JS 调用。

# Wasm 的生命周期（以 Rust 为例）
rust源码
 └─ rustc + wasm32 后端 → .wasm（字节码）
     └─ 浏览器引擎 AOT/JIT → 机器码
         └─ instantiate（实例化、建线性内存）
             └─ JS 调用 exports.xxx()
# 任一步出错：编译报错 / 实例化失败 / 调用签名不匹配

论为什么"实例化"值得注意

实例化会分配线性内存、建导入表，有不可忽略的开销（尤其大模块）。所以它不该放在"每次用户点击"里，而应在应用启动时做一次、复用实例。把实例化成本平摊到整个会话，单次调用的开销才真正低。

速查：Wasm 生态术语

初学常被一堆名词绕晕。下面这张速查表把它们的关系一次说清。

# 常见术语与一句话定位
.wasm      编译产物，字节码（不是源码）
Wat        文本格式，给人读/调试
wasm-pack  Rust→wasm 的编译打包工具
wasm-bindgen 自动生成 JS 胶水与 ABI
Emscripten C/C++→wasm 的工具链
WASI       服务端系统接口（能力导向）
WIT        组件模型里的接口定义语言

与 JS 互操作：宿主与客人

Host/Guest · 线性内存 · 导入/导出 · ABI

浏览器是"宿主（host）"，Wasm 模块是"客人（guest）"。客人没有 DOM 概念，想操作页面必须调用宿主提供的导入函数；数据通过一块双方共享的线性内存传递（要手动编解码）。这一章是 Wasm 最易踩坑、也最需要讲透的地方。

加载与调用：host/guest 模型

JS 负责把 .wasm 拉下来、实例化，然后调用它导出的函数。整个过程是异步的——别忘 await。

为什么是异步？因为下载 .wasm 是网络 IO，编译成机器码也要时间。如果你写同步写法，会在最开始卡住主线程，页面假死。所以 instantiateStreaming 返回 Promise，配合 await 是标准姿势。

还有一个细节：优先用 instantiateStreaming 而非 instantiate。前者边下载边编译（流式），后者要等整个文件下载完再编译，慢一截。前提是服务器返回正确的 application/wasm MIME 类型，否则它会静默降级。

// JS 侧：加载并调用一个 wasm 导出的函数
const mod = await WebAssembly.instantiateStreaming(fetch("app.wasm"));
const result = mod.instance.exports.fib(20);  // 调 Rust/C 编出的函数

线性内存：双方共享的一块连续字节

Wasm 没有"对象"概念，只有一块叫线性内存的扁平字节数组（底层是 ArrayBuffer）。JS 和 Wasm 都通过偏移量读写它。所有复杂数据（字符串、数组、结构体）都要先序列化进这块内存，对方再按约定偏移反序列化。

// JS 往线性内存第 0 字节写一个 ASCII 字符 'A'
const mem = mod.instance.exports.memory;
const buf = new Uint8Array(mem.buffer);
buf[0] = 65;   // Wasm 侧可从偏移 0 读到这个字节

论线性内存是"共享黑板"

把它想成 JS 和 Wasm 之间的一小块公共黑板：JS 写、Wasm 读，或反过来。难点不在"能不能写"，而在"约定好格式"——谁在第几个字节、几个字节表示一个值。格式没对齐，读出来的就是乱码。这正是 ABI 要解决的问题。

导入与导出：模块的嘴和手

Wasm 用 导出（export） 把函数/内存暴露给宿主调用；用 导入（import） 声明"我需要宿主提供某函数"。没有导入，Wasm 几乎做不了任何对外部有副作用的事。

这个"导入/导出"机制，本质上就是宿主和客人之间的"契约"。Wasm 声明"我需要 env.log"，宿主就必须提供；不提供，实例化直接失败。契约不匹配，连跑都跑不起来——这反而是安全的：你没法偷偷调用一个没声明的危险能力。

对比普通 JS：一段 JS 能直接 fetch、直接碰 document，谁也拦不住。Wasm 则在设计上把"能做什么"白纸黑字写在模块头部，运行时按清单授予。这种"默认拒绝、显式授予"正是它适合跑不可信代码的底层原因。

// 宿主提供 log，Wasm 导入后调用（Wat 表达）
(module
  (import "env" "log" (func $log (param i32)))
  (func (export "run")
    i32.const 42
    call $log))   // 把 42 交给宿主的 log

字符串/数组传递：手写 ABI

字符串不能直接跨边界。标准做法是：用 TextEncoder 把字符串变成 UTF-8 字节，写入线性内存某偏移，再把"偏移 + 长度"两个 i32 传给 Wasm；Wasm 按偏移读取字节、解码成自己的字符串。

// JS 侧：把字符串写入内存并把指针+长度交给 wasm
const bytes = new TextEncoder().encode("hi");
const ptr = mod.instance.exports.alloc(bytes.length);
new Uint8Array(mem.buffer, ptr, bytes.length).set(bytes);
mod.instance.exports.greet(ptr, bytes.length);  // 传指针+长度

数据传递有真实成本

JS 对象和 Wasm 内存不互通。传字符串/数组要拷贝进线性内存并管理偏移，频繁大块传递会成为新瓶颈。设计 API 时尽量减少跨边界数据搬运，能一次传一个 buffer 就别逐元素回调。

数据类型映射表

能直接穿过边界的只有"平面标量"。复合类型都得拆成标量或走内存。

JS 类型	能直接传？	做法
number (i32/f32/f64)	能	直接作参数/返回值
bigint (i64)	能（需配置）	JS 用 BigInt 接
string	不能	编码进内存，传指针+长度
object / array	不能	序列化进内存或靠 bindgen

// 传一个 i64 与一个大数组的两个例子
const big = wasm.exports.count(BigInt(9007199254740991));
const arr = wasm.exports.sum_list(Uint32Array.from([1,2,3]));
# 标量直接传；对象/数组经 bindgen 自动序列化进内存

调用开销与边界

单次调用本身很便宜（纳秒级），但类型转换（尤其字符串/对象经 bindgen）有成本。关键不是"调一次多贵"，而是"调了多少次、传了多大"。下面这张表帮你判断该不该下沉。

调用模式	开销	建议
Wasm 内部算 100 万元素	极低	强烈适合
JS→Wasm 单次调用	低（纳秒级）	可接受
循环里每元素都回调 JS	极高	千万别
传超大字符串跨边界	中（拷贝）	批量传 buffer

实战：一次完整的 JS↔Wasm 来回

把前面零散的知识点串成一个最小闭环：JS 分配内存 → 写入字符串 → 调用 Wasm 把它转大写 → 读回结果。这正是 bindgen 替你做的"脏活"的底层样子。

// 假设 wasm 导出 alloc(len) 与 to_upper(ptr, len)
const src = new TextEncoder().encode("hello");
const ptr = mod.exports.alloc(src.length);
new Uint8Array(mem.buffer, ptr, src.length).set(src);
mod.exports.to_upper(ptr, src.length);   // wasm 原地改内存
const out = new Uint8Array(mem.buffer, ptr, src.length);
console.log(new TextDecoder().decode(out));  // "HELLO"

论为什么平时不用这么写

手写这套"分配-写入-调用-读回"既易错又难维护。wasm-bindgen 把内存管理、编码解码全包了，让你直接 wasm.to_upper("hello") 拿到字符串。理解底层是为了出问题时会排查，日常开发请交给 bindgen。

Rust → WebAssembly：工具链与内存

wasm-pack · wasm-bindgen · 所有权 · 调试

前面说的是"原理"，这一章动手。Rust 是 Wasm 最佳搭档：无 GC、产物小、工具链成熟。wasm-pack 负责编译打包，wasm-bindgen 负责自动生成 JS 胶水与 ABI。我们把一个 Rust 函数从写代码到在浏览器调通走一遍。

工具链：wasm-pack 与 wasm-bindgen

wasm-pack 把 Rust 项目编译成 .wasm 并生成配套 JS/TS 胶水；wasm-bindgen 是它的核心，负责在 Rust 类型和 JS 类型之间自动生成桥接代码，免得你手写下标偏移。

安装 wasm-pack 前要确保已有 Rust 工具链（rustup）。如果你机器上还没有 Rust，第一步是装 rustup 而非 wasm-pack——新手常在这里卡住，报一堆"command not found"。

--target web 产出的是给浏览器直接用的 ES Module 胶水；还有 --target nodejs（给 Node 用）、--target bundler（给 webpack/Vite 用）。选错 target，前端 import 的方式就不对。浏览器项目一般选 web 或 bundler。

# 安装工具链（需先有 Rust 工具链）
cargo install wasm-pack
# 构建：目标 web，发布模式（体积最小、最快）
wasm-pack build --target web --release

论为什么不用 Emscripten 也能行

Emscripten 主要服务 C/C++；Rust 走自己的 wasm32-unknown-unknown 后端 + wasm-bindgen，产物更小、对 Web 更友好。所以 Rust 项目首选 wasm-pack，C/C++ 项目才考虑 Emscripten。两者目标一致：把原生代码安全地跑进沙箱。

第一个 Rust→Wasm 函数

一个最朴素的导出函数：不用 bindgen，直接以 C ABI 暴露，参数返回值都是平面 i32。

// src/lib.rs
#[no_mangle]
pub extern "C" fn add(a: i32, b: i32) -> i32 {
    a + b
}

编译后，JS 里就能 wasm.exports.add(2, 3) 拿到 5。这种"裸 C ABI"适合极简场景；一旦涉及字符串/数组，手写内存管理会很痛，这时上 wasm-bindgen。

;; 该函数编译后的 Wat 大致长这样
(func $add (param $a i32) (param $b i32) (result i32)
  local.get $a
  local.get $b
  i32.add)
# 裸 C ABI：参数/返回值都是平面 i32，无字符串自动处理

内存与所有权：返回 String 会发生什么

Rust 的 String 在 Wasm 线性内存里。当函数返回 String 给 JS 时，bindgen 会把它复制到 JS 能持有的形式（如 JS String）并释放 Wasm 侧内存。你基本不用手动管，但要理解"这是一次拷贝"。

这里藏着 Rust 所有权模型在边界上的投影：跨语言时"谁释放"必须明确。如果 Wasm 分配了一块内存又忘了释放，而 JS 这头以为 bindgen 会管，就会泄漏；反之若 JS 释放了 Wasm 还在用，就野指针。bindgen 生成的胶水把这套规则固化了，所以新人基本不用手写。

但一旦你为了极致控制走"裸 C ABI + 手动 alloc/free"，这套保障就没了——你必须自己保证对称释放。这也是为什么除非性能极致敏感，否则一律用 bindgen：把内存安全的复杂性交给生成器，而不是自己的脑子。

// bindgen 自动处理字符串的跨边界拷贝
#[wasm_bindgen]
pub fn greet(name: &str) -> String {
    format!("Hello, {}!", name)
}

论所有权在边界上意味着什么

跨语言的"所有权"本质是谁负责释放那块内存。bindgen 生成的胶水会确保 Wasm 分配的内存最终被 Wasm 的分配器收回，不会内存泄漏。只要你走 bindgen 而非手动 malloc/free，这块通常不用操心——这也是推荐 bindgen 而非裸 C ABI 的原因。

与 JS 互调：wasm-bindgen 的甜头

bindgen 让你直接用 Rust 类型写函数，它生成对应的 JS 包装。下面这个函数接收一个数组并返回求和，JS 侧就像调用普通函数一样用。

这里有个容易被忽略的点：bindgen 在"传数组"时默认会拷贝一份。你传给 sum_slice([1,2,3,4]) 的 JS 数组，会被复制进线性内存，Wasm 在内存里算，结果再拷回来。对于只读输入这没问题；但若你在 Wasm 里改了它，JS 侧的原始数组不会变——因为那是两份。

所以"&[i32] 是只读引用"在 Rust 侧是常识，在跨语言边界上则意味着"这是从 JS 拷进来的快照"。需要双向修改时，要走显式的"分配—传指针—取回"流程，而不是指望引用共享。

// Rust 侧：bindgen 自动把 &[i32] 与 JS 数组互转
#[wasm_bindgen]
pub fn sum_slice(data: &[i32]) -> i32 {
    data.iter().sum()
}

// JS 侧：import 生成的胶水，像普通函数一样调用
import init from "./pkg/mylib.js";
const wasm = await init();
console.log(wasm.sum_slice([1, 2, 3, 4]));  // 10，无需手写 ABI

别在热循环里反复传大数组

bindgen 虽自动化了拷贝，但"每次调用都拷贝一份大数组"在热路径上依然贵。如果要在 Wasm 内反复处理同一份数据，传一次进去、在 Wasm 内部循环处理、只把结果传回，比"JS 循环 → 每次传一个元素"高效得多。

调试：让 panic 现形

Wasm 里 Rust panic 默认是"静默中止"，浏览器只看到一句莫名其妙的 trap。接入 console_error_panic_hook 后，panic 信息会打印到控制台，定位问题快很多。

// 在 lib.rs 入口启用 panic 打印
use console_error_panic_hook::set_once;
#[wasm_bindgen]
pub fn start() {
    set_once();   // 之后任何 panic 都会打到 console
}

论调试的另一半是"看生成的 JS"

wasm-pack 生成的 pkg/mylib.js 是真实胶水代码。出问题时别只盯着 Rust，打开它看 bindgen 到底怎么传参——很多时候"调不通"是因为 JS 侧传的类型和 Rust 签名对不上。

体积优化：别把胖子塞进首屏

编译产物可能包含未用代码。wasm-opt（来自 binaryen）能做激进的尺寸优化；同时开 LTO 和 opt-level = "z" 进一步瘦身。

# 用 binaryen 的 wasm-opt 做尺寸优化
wasm-opt -Oz -o out.wasm in.wasm
# 或在 Cargo.toml 的 [profile.release] 设 opt-level="z"、lto=true

论体积为什么重要

Wasm 通常在页面加载时就要下载并编译。一个 5MB 的模块会让首屏明显变慢，抵消性能优势。能用 wasm-opt 瘦到的都要瘦到，必要时按需懒加载，而不是一进页面就全量拉取。

发布与集成：从 cargo 到网页

wasm-pack 的产物是一个 pkg/ 目录（含 .wasm、.js 胶水、.d.ts）。前端项目直接 import 这个 js 即可，构建工具（Vite/webpack）会处理剩下的打包。

# 构建产物结构
pkg/
  mylib.wasm     # 字节码
  mylib.js       # 胶水（import 它即可）
  mylib.d.ts     # 类型声明（TS 友好）
// 前端代码里
import init from "mylib";
const wasm = await init();
wasm.do_work();   // 像调本地函数

集成时常踩的坑

① 忘了 await init：胶水返回 Promise，直接调函数会报"未初始化"。② 构建工具没配 wasm 加载：Vite 默认支持，但某些配置下需加插件，否则报"无法加载 .wasm"。③ 把 pkg 当普通 npm 包发却漏了 .wasm：确保 files 字段包含它。

性能与安全模型

原生速度 · 边界检查 · 沙箱 · 何时更慢

为什么 Wasm 快？为什么它安全？这一章把性能和安全的底层逻辑讲清，并诚实地告诉你"什么时候它反而更慢"。

为什么能"接近原生速度"

Wasm 是紧凑的、带类型的低级字节码，引擎可以非常高效地把它编译（或解释）成机器码；它没有 JS 那样的动态类型、隐藏类、GC 停顿等不确定性开销。再加上线性内存是连续、可预测的，CPU 缓存命中率高。

具体快多少，取决于任务。纯数值循环（矩阵乘法、图像处理、物理仿真）常常快 5~20 倍于等效 JS，因为 JS 引擎要为每次操作做类型检查与装箱拆箱，而这些在 Wasm 里是确定的。但如果是"算两个数然后立刻更新 DOM"，那点算力省下的 time 远小于 DOM 操作本身的 time——此时 Wasm 毫无优势。

所以"快"是有条件的：计算占比高、与 DOM 交互少、数据能成块处理。记住这三条，你就能在动手前预判 Wasm 值不值得上，而不是等写完了才测出来"怎么没变快"。

论"接近原生"不是"等于原生"

Wasm 仍跑在引擎之上，有编译/实例化成本和一层抽象；在极端场景下略慢于手写的本地机器码是正常的。但相比"被 JIT 反复揣测类型"的 JS，它在数值密集任务上通常快一个数量级，这正是价值所在。

跨边界调用的开销

单次调用便宜，但类型转换（尤其字符串/对象经 bindgen）有成本。关键不是"调一次多贵"，而是"调了多少次、传了多大"。下面这张表帮你判断是否值得下沉。

调用模式	开销	建议
Wasm 内部算 100 万元素	极低	强烈适合
JS→Wasm 单次调用	低（纳秒级）	可接受
循环里每元素都回调 JS	极高	千万别
传超大字符串跨边界	中（拷贝）	批量传 buffer

// 反例：在循环里反复回调 JS，边界开销爆表
for (let i = 0; i < n; i++) {
  wasm.exports.on_each(i);   // 每次都跨边界 → 慢
}
// 正例：把循环搬进 Wasm，只调一次
wasm.exports.process_all(n);  // 内部循环，零边界开销

边界检查与沙箱：安全从架构来

Wasm 的内存安全是结构性的：线性内存是一段连续的、有长度限制的数组，任何越界访问在引擎层就被拦下，不可能像 C 那样踩到别的进程内存。再加上"无系统权限"的沙箱，运行不可信代码的风险被压到很低——这正是它适合做插件/第三方扩展的底气。

论沙箱 ≠ 完全无害

沙箱保证了"它动不了操作系统"，但不保证"它不卡死你的主线程"或"它不疯狂吃内存"。恶意/有 bug 的 Wasm 仍可能死循环或耗尽线性内存。所以宿主侧仍要配超时、内存上限、最坏情况降级——沙箱是底盘，不是全部。

何时 Wasm 反而更慢

别盲信"Wasm 一定快"。以下场景它可能比纯 JS 还慢。

最容易被忽略的是第 ④ 条：debug 构建的 Wasm 比你想的慢得多。编译器为了保留调试信息、不做内联，生成的代码臃肿。网上那些"Wasm 只快一点点"的翻车测评，很多其实没开 release。做对比务必两边都走优化模式，否则结论毫无意义。

还有个隐含前提：Wasm 的"快"要能覆盖固定成本。编译+实例化可能耗时几十毫秒，如果你的函数总共才跑 5 毫秒，那固定成本反而 dominate。所以 Wasm 适合"长期驻留、被反复调用"的场景，而非"调一次就扔"。

Wasm 反而更慢的情形

① 计算量很小：那点算力省不下，反而被"编译+实例化+边界调用"的固定成本吃掉。② 频繁跨边界：每次都回调 JS，开销累加超过计算收益。③ 强 DOM 交互：逻辑本就在操作 DOM，绕一圈进 wasm 再出来纯属多余。④ 没用发布模式：debug 构建的 Wasm 可能比优化后的 JS 慢得多。

做一场诚实的基准对比

判断是否值得下沉，用数据别用信仰。在真实输入规模下，对比 JS 实现与 Wasm 实现（都走发布/优化模式）的耗时。注意要包含"编译+实例化"的一次性成本——小任务里它可能占比惊人。

// 测 Wasm 热点函数耗时（含必要初始化）
const wasm = await init();
const t0 = performance.now();
const out = wasm.heavy_compute(N);   // 热点
const dt = performance.now() - t0;
console.log(`wasm 耗时 ${dt} ms`);

线性内存的扩容：memory.grow

线性内存初始有固定页数（每页 64KB）。若 Wasm 内部需要更多空间，可调用 memory.grow(n) 追加页数。但扩容后内存地址会变（原有数据被搬到新基址），所以别在 JS 侧缓存旧指针。

// Wasm 内部申请更多内存（页数，每页 64KB）
let cur = memory.grow(4);  // 再要 4 页；返回旧页数
// JS 侧若持有了旧偏移，grow 后需重新获取 mem.buffer

论为什么 JS 侧要重拿 buffer

grow 可能触发底层 ArrayBuffer 替换，旧的 Uint8Array 视图 会"悬空"。正确做法是每次访问前重新从 memory.buffer 建视图，或监听内存变化。这是 Wasm 与 JS 协作里最容易踩的"指针失效"坑。

基准分数的诚实结论

网上常见"Wasm 比 JS 快 N 倍"的 benchmark，多半是挑选了最有利的场景（纯数值、大循环）。真实项目里，收益取决于"计算占比 vs 跨边界占比"。一个诚实的结论是：Wasm 在"重计算、少交互"的任务上稳赢，在"大量 DOM/频繁回调"的任务上未必。

别拿 benchmark 当承诺

如果有人拿一个合成 benchmark 说服你"全站上 Wasm"，先问：他那 benchmark 的负载像不像你的真实负载？合成测试和真实应用的差距，常常比"Wasm vs JS"本身的差距还大。永远用自己业务的真实输入测。

典型应用：哪里该用 Wasm

Use Cases · 插件 · 边缘 · 游戏 · 搬库

Wasm 不是"什么都用"，而是"在它擅长的地方大放异彩"。这一章列清主流场景，每个都配一句"为什么这里它赢了"。

插件 / 沙箱化扩展系统

很多产品允许用户写"插件"扩展功能（如 Figma 插件、数据库 UDF、编辑器扩展）。让第三方代码在 Wasm 沙箱里跑，既给了用户编程能力，又保证它碰不到你的主程序、文件系统、密钥——这是 Wasm 最优雅的用法之一。

插件场景里有一个常被低估的价值：隔离带来"可计费"。因为每家用户的插件在独立沙箱里跑、资源可控，平台才能安全地按调用量收费，而不怕某用户插件把整台服务器拖垮。没有 Wasm 这种"强隔离+轻量"的组合，多租户插件市场很难成立。

反过来想：如果你做的不是"开放给第三方写插件"，而是"自己团队写内部扩展"，那 iframe 或独立服务可能更简单。Wasm 插件的价值，主要在"执行不可信代码"这五个字上。可信的内部代码，未必需要这套复杂度。

// 宿主加载用户插件（只给受限导入，不给危险能力）
const imports = { env: { log: (m) => console.log(m) } };
const plugin = await WebAssembly.instantiate(userBytes, imports);
plugin.exports.run(userInput);   // 沙箱里执行，伤不到宿主

论为什么不用 iframe / docker 做插件

iframe 隔离的是 DOM 但性能弱、通信烦；docker 隔离强但太重、启动慢。Wasm 介于两者之间：毫秒级启动、可嵌入进程内、又保持内存隔离，特别适合"轻量、高频、不可信"的扩展逻辑。

边缘计算：把逻辑推到离用户最近处

CDN 边缘节点要在几毫秒内改写请求、做 A/B、过滤攻击。Wasm 体积极小、启动毫秒级、沙箱安全，相比"为每个边缘函数起一个容器"，它快几个数量级。Cloudflare Workers、Fastly 等正是基于这个判断拥抱 Wasm。

论边缘 Wasm 与浏览器 Wasm 的关系

同一份 .wasm，既能在浏览器跑（处理图像），也能在边缘跑（处理请求）。"一次编译、到处安全运行"是 Wasm 的愿景——只是浏览器里受 Web 平台限制，边缘/服务端则靠 WASI（见第 6 章）解锁系统能力。

// 边缘 Worker 里跑 Wasm（伪代码）
const wasm = await init();
addEventListener("fetch", (req) => {
  const out = wasm.exports.rewrite(req.body);
  return new Response(out);   // 毫秒级改写请求
});

游戏 / 音视频 / 物理仿真

这类场景的共同点是每帧海量数值计算，正是 Wasm 的主场。Unity、Bevy、Godot 等引擎已支持导出到 Wasm，让原本桌面的游戏/工具跑进浏览器。

场景	为什么 Wasm 合适
游戏引擎	渲染/物理每帧巨量计算，原生速度必需
音视频编解码/滤镜	逐帧像素运算，JS 太慢
CAD / 3D 建模	几何运算密集，需稳定低延迟
科学仿真	矩阵/数值积分，CPU 密集

// 游戏主循环里把物理计算下沉到 Wasm（示意）
function frame() {
  wasm.exports.step_physics(dt);   // 每帧巨量向量运算
  render();
  requestAnimationFrame(frame);
}

把现有 C/C++/Rust 库搬上 Web

很多高质量算法（SQLite、图像库、编解码器、加密库）早有成熟的 C/C++ 实现。用 Emscripten 或 wasm-pack 把它们编译成 Wasm，就能直接在浏览器复用，免去用 JS 重写一遍（且重写很难达到同等质量/性能）。

这类"搬库"之所以香，是因为它复用的是经过十年打磨的 C/C++ 实现。比如 SQLite、zlib、OpenCV，其正确性和性能都已被海量生产环境验证。用 JS 重写一遍，不只是慢，更可能写出一堆边界 bug。编译进 Wasm，等于"站在巨人肩膀上"。

但要警惕"为了搬而搬"。先确认 JS 生态里没有够用的等价物。很多时候一个成熟 npm 包就能解决，强行上 Wasm 只是给团队增加维护负担。Wasm 搬库适合"核心算法、性能敏感、且只有 C/C++ 实现"这三类交集。

# 用 Emscripten 把 C 库编成 wasm（生成 .js 胶水 + .wasm）
emcc lib.c -O3 -s WASM=1 -s MODULARIZE=1 -o lib.js
# 之后 JS 里 Module.then(m => m._some_fn(...)) 调用

搬库的两个坑

① 依赖系统调用：C 库若大量用文件/网络，浏览器里没有，需要 Emscripten 的虚拟文件系统或改写。② 体积：大库编译后 wasm 可能好几 MB，要考虑首屏。先用 wasm-opt 瘦身，必要时懒加载。

案例：浏览器里的图像滤镜

一个典型成功案例：用户上传图片，前端用 Wasm 做锐化/压缩/ OCR 预处理，既快又不把原图传服务器（隐私友好）。模式是"JS 负责选文件+展示，Wasm 负责像素计算，结果回传 canvas"。这正是"热点下沉"的标准姿势。

这个模式的延展性很好：同一份 Wasm 计算模块，前端能用，服务端也能用。比如把图片压缩逻辑编译成 wasm32-wasi，服务端批量处理时直接复用，避免"前端 JS 一套、后端 Python 一套"的对不齐。一份算法，两处受益。

但也要注意隐私边界的另一面：把计算放浏览器，意味着敏感数据不出客户端，这是优点；可一旦逻辑本身需要服务端密钥或数据库，就必须老实回传服务器——别为了"快"或"隐私"强行把所有东西都塞进前端。

论判断一个需求该不该上 Wasm 的口诀

问自己三句：① 这里是性能瓶颈吗？（先用 JS 写出来测，别预判）② 计算能成块下沉、少跨边界吗？③ 有现成 Rust/C 实现可编译吗？三句都"是"，再上 Wasm；否则先用 JS，别提前复杂化。

明确"不该用 Wasm"的场景

这一章讲了好多能用，但克制地不用同样重要。下面这些场景，上 Wasm 基本是给自己加戏。

这些就别上 Wasm 了

① 普通表单 / 增删改查页：瓶颈在 IO 和交互，不在计算。② 只是想"显得先进"：没有性能问题硬上，反而增加构建与调试成本。③ 强依赖现成 JS 生态：若功能已经有个成熟 npm 包，重写进 Wasm 纯属重复造轮子。④ 团队没人懂 Rust/C：源语言门槛会卡住整个维护链路。

案例：数值密集的后端批处理

不止浏览器——服务端也能用 Wasm 跑重计算。例如对海量记录做特征变换：用 Rust 写核心循环，编译成 Wasm 在边缘/函数里对每个请求实时算，比"起一个常驻服务"更轻。

// 一个被编译进 Wasm 的特征计算（Rust 侧）
#[wasm_bindgen]
pub fn transform(input: &[f64]) -> Vec<f64> {
    input.iter().map(|x| (x * 2.0 + 1.0).sqrt()).collect()
}

论同一个函数，两种部署

上面这个函数，编译到 wasm32-unknown-unknown 能在浏览器跑；编译到 wasm32-wasi 能在服务端运行时跑。一份算法代码，前后端/边缘共用，避免"浏览器一套 JS、服务端一套 Python"的对不齐——这是 Wasm 跨平台价值的真正落点。

与容器 / Serverless：WASI 与组件模型

WASI · Component Model · 轻量运行时

Wasm 不止属于浏览器。随着 WASI（WebAssembly System Interface） 和 组件模型（Component Model） 成熟，它正成为"云原生时代的轻量可移植运行时"——在边缘、Serverless、插件平台与容器争夺地盘。这一章讲清服务端那条线。

WASI：让 Wasm 安全地碰系统

浏览器里 Wasm 不能碰系统；但在服务端我们需要它读文件、用网络。WASI 是一套"能力导向"的系统接口：模块声明自己需要什么能力（如"读某个目录"），由宿主按需授权，而非默认拥有全部权限。这把浏览器的安全模型带到了服务端。

打个比方：传统进程像个拿到你家门钥匙的租客，能进能出能翻柜子；WASI 下的 Wasm 模块像个只能进"你指定那间房"的访客，别的门根本不存在。宿主（运行时）是门禁，模块自己无法越权。

这让"运行用户上传的代码"在服务端变得可行且安全——以前你得给每个用户起一个 Docker 容器（重），现在可以一个进程里跑成百上千个 Wasm 访客（轻）。多租、高密度、强隔离，三者难得地兼得了。

// 一个用 WASI 的 Rust 程序（编译到 wasm32-wasi）
fn main() {
    println!("hello from wasi");  // 打印经 WASI 授权
}
# 构建：rustup target add wasm32-wasi
# cargo build --target wasm32-wasi --release
# 运行：wasmtime app.wasm   （运行时按策略授权）

论WASI 的"能力"思维

传统进程默认拥有运行用户的全部权限（能读能写能联网），靠 OS 用户隔离。WASI 反过来：默认什么都不能，要什么显式申请。这天然适配"不可信/多租户"场景，是它比普通容器更安全的根源。

组件模型 Component Model：模块化拼装

早期 Wasm 模块之间几乎不能"对话"（没有统一类型/接口）。组件模型 + WIT 接口定义语言让不同语言编出的组件能像乐高一样组合：一个用 Rust 写、一个用 JS 写，通过约定的接口无缝调用，且依然保持沙箱隔离。

// WIT：定义组件间的接口（与语言无关）
interface logger {
  log: func(msg: string);
}
world app {
  import logger;        // 需要宿主提供 logger
  export run: func();  // 对外暴露 run
}

论为什么组件模型重要

它把 Wasm 从"单个函数"升级为"可组合的服务单元"。想象：一个团队用 Rust 写加密组件、另一个用 Go 写网络组件、前端用 JS 写编排，三者编译成组件后拼成同一应用。这是"用最合适的语言写最合适的部分"的终极形态。

轻量运行时：Wasm 与容器的对比

Wasm 运行时（Wasmtime、WasmEdge、Wasmer）启动是毫秒级、内存KB 级，而容器要起一个完整 OS 进程、百 MB 起步、秒级启动。在"海量短命函数"场景，差距就是成本差距。

为什么"短命函数"场景差距尤其大？因为容器的成本大头在"启动 + 常驻内存"，函数只跑 10 毫秒却要为它付秒级启动和百 MB 常驻的代价，利用率极低。Wasm 几乎零启动、几 KB 常驻，把这部分浪费几乎抹平——函数越多、越短命，省得越多。

但反过来，长时间运行、稳定占用资源的服务，容器的"重"会被摊薄，此时 Wasm 的轻量优势就不明显了。所以"轻量运行时 vs 容器"没有绝对赢家，看负载画像。

维度	容器 (Docker)	Wasm 运行时
启动	秒级	毫秒级
内存基线	数十~数百 MB	数 KB~数 MB
隔离	OS 级（较重）	沙箱（轻、能力导向）
适用	长稳服务、重依赖	短命函数、边缘、插件

与容器的关系：替代还是互补

Wasm 不会"取代容器"。长生命周期、重 I/O、需要完整 Linux 环境的服务，容器仍是更省心的选择。但短命、高密度、多租户、需强隔离的"函数型"负载（边缘规则、事件处理、UDF），Wasm 明显更优。现实是两者并存，按负载选。

一个常见的架构是"容器跑主服务 + Wasm 跑边缘/函数"。数据库、长连接、重 I/O 留在容器里稳稳跑；把请求改写、A/B、UDF、风控这类"高频短命、需隔离"的逻辑用 Wasm 嵌在边缘或网关层。两者各司其职，比"全用容器"或"全用 Wasm"都更划算。

对团队而言，这意味着不必在"学容器"和"学 Wasm"之间二选一。先把手头的容器服务做扎实，再在合适的边缘/插件点引入 Wasm，是风险最低的演进路径。

论一个务实的选择框架

问：函数生命周期短、并发高、要求强隔离、要快启动？→ 倾向 Wasm。要跑数据库、要完整系统调用、长稳有状态？→ 倾向容器。很多平台（如 Fermyon、Cloudflare）直接把 Wasm 当"函数运行时"放在容器编排之上，互补而非二选一。

当前边界与适用前提

Wasm 服务端生态仍年轻，不是所有场景都该急着装。引入前确认团队能接受"工具链较新、轮子要自己造、调试不如原生顺手"的现实。

上 Wasm 服务端前先确认

① 真的有"高密度短命函数"需求吗？否则容器的成熟度和生态更划算。② 团队有 Rust/C 能力吗？Wasm 最佳源语言不是 JS。③ 现成运行时/平台选型清楚吗？（Wasmtime/WasmEdge/云厂商方案差异不小）。盲目追新，容易在技术债里挣扎。

用 Wasmtime 跑一个 WASI 程序

Wasmtime 是最常用的服务端 Wasm 运行时（由字节系开发，Rust 编写）。它负责实例化、按策略给 WASI 能力、执行。下面是把上一节的 hello 程序真正跑起来。

# 安装运行时
cargo install wasmtime
# 给"读取 ./data 目录"的能力，然后运行
wasmtime --dir ./data app.wasm
# 输出：hello from wasi（且它只能碰 ./data，碰不到别处）

论--dir 就是"能力授予"

注意 --dir ./data 不是"开个文件权限开关"，而是精确授予"这一个目录"。模块想读 /etc 会被拒。这种"最小授权"正是 WASI 比传统进程安全的地方——攻击面被运行时死死框住。

组件组合：多语言拼一个应用

组件模型的威力在于"不同语言编出的组件能无缝拼装"。下面是两个组件通过 WIT 约定的接口对接：加密组件（Rust）对外暴露 encrypt，编排组件（JS）导入它。

// 加密组件导出的 WIT 接口
interface crypto {
  encrypt: func(plain: string) -> string;
}
world provider {
  export encrypt;   // Rust 实现并导出
}
// JS 侧编排组件：import 上面的 crypto，直接调用
const cipher = await import("./crypto.component.wasm");
cipher.encrypt("secret");   // 跨语言、跨组件，像本地调用

论为什么这是范式变化

过去"微服务"之间靠网络协议（HTTP/gRPC）通信，重且有序列化成本。组件模型让同进程内的多语言模块像本地函数一样互调，又各自隔离。对"想用 Rust 写性能敏感部分、用 JS 写编排"的团队，这是梦寐以求的形态。

结

本页要点

WebAssembly 是一种可移植、接近原生速度、跑在沙箱里的字节码，由 Rust/C/C++/Go 编译而来，与 JS 是"伙伴而非替代"：JS 管 DOM/生态，Wasm 管重计算，经线性内存与导入/导出函数互调，字符串/数组需手写或靠 wasm-bindgen 自动 ABI 传递，且要警惕跨边界调用开销。Rust→Wasm 凭借无 GC、小体积、成熟工具链（wasm-pack/wasm-bindgen）成为首选路径，配合 console panic hook 与 wasm-opt 做调试与瘦身。它适用于图像/音视频/加密/游戏/搬库/插件沙箱/边缘计算；WASI 把"能力导向"的安全模型带到服务端，组件模型让多语言组件可组合，轻量运行时在启动与内存上碾压容器——但二者互补，且生态仍年轻，应按"高密度短命函数"这一前提理性选型。

自测 · 看你是否真懂

1.WebAssembly 会取代 JavaScript 吗？它们是什么关系？

查看答案

不会。Wasm 不能直接操作 DOM，需 JS 桥接；JS 负责生态与界面编排，Wasm 负责重计算。二者是伙伴而非替代，"热点下沉"才是正确用法——把性能瓶颈那块用 Wasm 重写，而非整套前端。

2.为什么字符串/数组不能直接从 JS 传给 Wasm？

查看答案

Wasm 只有"线性内存"这一块扁平字节数组，没有 JS 对象概念。字符串/数组要先用 TextEncoder 等编码进线性内存，再把"指针+长度"传过去，对方按约定偏移读取；返回时反过来。wasm-bindgen 能把这套 ABI 自动化，但底层仍是内存拷贝，频繁大块传递有成本。

3.为什么 Rust 特别适合编译到 Wasm？

查看答案

无 GC（产物小、启动快，不像带 GC 语言要把运行时一起打包）、零成本抽象、原生支持 wasm32 编译目标，配合 wasm-pack/wasm-bindgen 工具链成熟，能产出体积小、启动快的模块，是 Wasm 生态最活跃的源语言。

4.什么情况下用 Wasm 反而更慢？

查看答案

① 计算量本就很小时，省下的算力被"编译+实例化+边界调用"固定成本吃掉；② 在循环里频繁回调 JS，边界开销累加超过计算收益；③ 强 DOM 交互逻辑本就在操作 DOM，绕进 wasm 再出来纯属多余；④ 没用发布模式（debug 构建可能比优化后的 JS 还慢）。

5.WASI 是什么？它让 Wasm 在服务端意味着什么？

查看答案

WASI 是一套"能力导向"的系统接口，让 Wasm 模块能安全地申请使用文件、网络等系统能力（默认全无权限，要什么显式授权）。它把浏览器里的安全模型带到了服务端，配合轻量运行时（Wasmtime 等）实现毫秒级启动、KB 级内存、强隔离——使 Wasm 成为高密度短命函数/边缘/插件的理想运行时，但与容器互补而非取代。

下一步往哪走

路学完 Wasm 之后

① 补 Rust：去 tech-rust / tech-rust-ai，Wasm 的最佳源语言，先把所有权与工具链练熟。

② 串前端：回 tech-frontend-advanced，理解"何时该把计算下沉到 Wasm"，别在纯 UI 项目里硬上。

③ 动手：用 wasm-pack 把一个 Rust 图像处理函数编译成 wasm，在浏览器里调用，亲测边界开销。

④ 看服务端线：了解 WASI 与 Wasmtime/WasmEdge，试着把一个边缘函数用 Wasm 跑起来，对比容器启动成本。