WASM 技术栈月度总结：从编译到运行时的完整知识体系与关键概念

WASM 技术栈月度总结：从编译到运行时的完整知识体系与关键概念

一、WASM：我接触过最有欺骗性的技术

我第一次接触 WASM 是在 2025 年。当时听到一句话："用 Rust 写前端业务逻辑，编译到 WASM，JavaScript 可以直接调用。"我心想：这跟把 Python 编译成 exe 有什么区别？没什么了不起的。

一年后，我意识到自己完全错了。

WebAssembly 的核心价值不是"让 Rust 能在浏览器里跑"，而是定义了一套与语言无关、与宿主无关的沙箱化执行标准。这意味着同一个 .wasm 二进制可以在浏览器里跑、在 Node.js 里跑、在 AWS Lambda 里跑、在边缘 CDN 上跑、甚至在嵌入式设备上跑。

这个 7 月，我在 dayuan 项目里深度使用 WASM 做三件事：① 浏览器端的 AI 模型推理；② CLI 工具的插件系统；③ WASI 运行时探索。这篇文章是我对这个技术栈的完整知识总结。

二、WASM 技术栈全景图

三、关键概念深度拆解

概念一：wasm32-unknown-unknown 到底是什么？

这个令人困惑的目标三元组是理解 WASM 编译的第一关。

wasm32-unknown-unknown
  │      │       │
  │      │       └── 操作系统（wasm 不绑定特定 OS）
  │      └────────── 厂商（没有特定厂商）
  └───────────────── 架构（32 位 WASM）

对比一下常见的 Rust 编译目标：

/// 条件编译：根据编译目标选择不同的代码路径
/// 这是 WASM + 非 WASM 代码共存的常用模式

/// 获取当前时间戳
pub fn get_timestamp() -> u64 {
    // cfg! 宏：编译时条件判断
    if cfg!(target_arch = "wasm32") {
        // 在浏览器 WASM 环境：用 JS 的 Date.now()
        // 因为 WASM 没有系统时钟！
        web_sys::window()
            .and_then(|w| w.performance())
            .map(|p| p.now() as u64)
            .unwrap_or(0)
    } else {
        // 在本地/服务器环境：用标准库
        std::time::SystemTime::now()
            .duration_since(std::time::UNIX_EPOCH)
            .unwrap()
            .as_millis() as u64
    }
}

/// 读取文件内容
/// WASM 环境没有 std::fs，需要通过 JS 桥接
#[cfg(target_arch = "wasm32")]
pub async fn read_config() -> String {
    // 在 WASM 中通过 fetch API 获取配置文件
    let window = web_sys::window().unwrap();
    let resp = wasm_bindgen_futures::JsFuture::from(
        window.fetch_with_str("config.toml")
    ).await.unwrap();
    // ... 解析响应
    todo!()
}

#[cfg(not(target_arch = "wasm32"))]
pub async fn read_config() -> String {
    // 在本地环境直接用标准库
    std::fs::read_to_string("config.toml").unwrap()
}

概念二：WASM 的线性内存模型

这是 WASM 最核心的设计之一，也是最容易误解的地方。

┌─────────────────────────────────────┐
│           WASM 线性内存              │
│  (一块连续的 byte 数组，从 0 开始)    │
│                                     │
│  ┌─────── 栈区域 ───────┐           │
│  │ 局部变量、函数调用帧   │           │
│  │ (从高地址向低地址增长) │           │
│  └──────────────────────┘           │
│                                     │
│  ┌─────── 堆区域 ───────┐           │
│  │ 全局数据、动态分配     │           │
│  │ (从低地址向高地址增长) │           │
│  └──────────────────────┘           │
│                                     │
│  总大小：初始页数 × 64KB            │
│  可通过 memory.grow 动态扩展        │
└─────────────────────────────────────┘

/// WASM 内存管理的核心区别
use wasm_bindgen::prelude::*;

/// ❌ 不能直接返回 Vec<u8> 给 JS
/// Vec 的内存布局是 Rust 特有的，JS 无法理解
/// 这会在运行时导致 wasm-bindgen 报错

/// ✅ 方案一：拷贝数据到 WASM 线性内存，返回指针
#[wasm_bindgen]
pub fn get_data_pointer() -> *const u8 {
    // 数据分配在 WASM 的线性内存中
    static DATA: &[u8] = b"Hello from WASM!";
    DATA.as_ptr()  // 返回线性内存中的地址
}

/// ✅ 方案二：使用 wasm-bindgen 的自动转换
#[wasm_bindgen]
pub fn get_data_vec() -> Vec<u8> {
    // wasm-bindgen 自动处理 Vec → Uint8Array 的转换
    // 实际上是拷贝数据到 JS 的堆内存
    b"Hello from WASM!".to_vec()
}

/// ✅ 方案三：大数据量时用共享内存避免拷贝
/// 使用 JavaScript 的 SharedArrayBuffer
/// 但需要 COOP/COEP 头，有安全限制

概念三：WASI —— WebAssembly 离开浏览器的钥匙

WASI（WebAssembly System Interface）是让 WASM 能在浏览器之外运行的关键标准。它定义了一套系统级接口：文件系统、网络、时钟、随机数等。

/// WASI 预览版2 示例：用 Rust 写一个 WASI 程序
/// 编译：cargo build --target wasm32-wasip2

use std::fs;
use std::io::{self, Write};

fn main() -> io::Result<()> {
    // ① 读取文件（通过 WASI 的 fd_read 接口）
    let content = fs::read_to_string("input.txt")?;
    
    // ② 处理数据
    let processed = content.to_uppercase();
    
    // ③ 写入文件（通过 WASI 的 fd_write 接口）
    let mut file = fs::File::create("output.txt")?;
    file.write_all(processed.as_bytes())?;
    
    Ok(())
}

// 运行方式（使用 wasmtime）：
// wasmtime run --dir=. program.wasm
// --dir=. 表示允许 WASM 程序访问当前目录（预打开）
// WASI 的沙箱模型：默认禁止一切，显式授权

WASI 的核心安全模型：能力（Capability）授予

# 没有 --dir 参数：程序无法访问任何文件系统
wasmtime run program.wasm

# 授予只读访问 ./data 目录的能力
wasmtime run --dir=./data::ro program.wasm

# 授予网络访问的能力（WASI 预览版2）
wasmtime run --tcplisten=127.0.0.1:8080 program.wasm

# 这就是"最小权限原则"在运行时层面的实现
# 即使程序有远程代码执行漏洞，攻击者也看不到你的 ~/.ssh 文件

概念四：wasm-pack —— 让 Rust 变成前端的一部分

/// 用 wasm-pack 构建一个前端可用的 WASM 模块
/// 步骤：wasm-pack build --target web

use wasm_bindgen::prelude::*;
use serde::{Serialize, Deserialize};

/// 导出一个 Rust 函数给 JS 调用
#[wasm_bindgen]
pub fn greet(name: &str) -> String {
    format!("你好，{}！这是来自 Rust 的问候。", name)
}

/// 导出结构体（自动映射到 JS 类）
#[wasm_bindgen]
pub struct MarkdownParser {
    options: ParserOptions,
}

#[wasm_bindgen]
impl MarkdownParser {
    /// 构造函数：new 会被映射为 JS 的 new MarkdownParser()
    #[wasm_bindgen(constructor)]
    pub fn new() -> Self {
        Self {
            options: ParserOptions::default(),
        }
    }
    
    /// 解析 Markdown（Rust 高性能处理 + WASM 安全沙箱）
    pub fn parse(&self, input: &str) -> String {
        // 使用 Rust 的 pulldown-cmark 做高性能 Markdown 解析
        let parser = pulldown_cmark::Parser::new(input);
        let mut html_output = String::new();
        pulldown_cmark::html::push_html(&mut html_output, parser);
        html_output
    }
}

// JS 侧调用：
// import init, { MarkdownParser } from './pkg/my_module.js';
// await init();
// const parser = new MarkdownParser();
// const html = parser.parse("# Hello\n\n这是 **Markdown**");

实战踩坑记录

我在用 wasm-bindgen 导出第一个函数时就踩了坑——Rust 的 String 会自动转成 JS 的 String，但 JS 的 String 转回 Rust 的 String 时，如果包含 emoji（4 字节 Unicode），会触发性能很差的解码路径。后来统一用 Uint8Array 传二进制数据，在 Rust 侧做 UTF-8 解码，性能提升了 6 倍。

另一个坑是 WASM 的 panic 处理。Rust 的 panic! 在 WASM 里默认会调用 abort()，整个 WASM 实例就废了。我们在 #[wasm_bindgen] 函数里统一用 Result<T, JsValue> 返回错误，绝不让 panic 传播到 WASM 边界之外。这个规则写在了项目 README 的第一条，也是每个新成员入职必读的内容。

四、WASM 技术栈选型决策指南

我们做了一个 benchmark：同样一个 Markdown 解析任务，原生 JS 实现耗时 112ms，Rust 编译到 WASM 耗时 18ms——6.2 倍加速。但加速器取决于任务类型：计算密集型（加密、压缩、解析）WASM 快 3-8 倍，内存密集型（大数组排序）快 1.5-2 倍（受线性内存拷贝影响），I/O 密集型（网络请求、文件读取）WASM 无优势，因为 I/O 本身就在 JS 侧。

所以 WASM 不是万能的。我们的经验是：先写 JS 原型，用 Chrome DevTools Performance 面板找到热点函数，再考虑用 Rust + WASM 重写那个热点。全套 WASM 化反而会增加构建复杂度和包体积，不值得。

五、总结

WASM 技术栈的核心认知可以总结为二句话：

1. WASM 不是"浏览器里的汇编"，而是"平台无关的安全沙箱字节码"。
2. WASI 让 WASM 从浏览器走向服务器，它的"能力授予"安全模型比 Linux 容器更优雅。

对于同学，我建议的学习路径是：

• 第一周：用 wasm-pack 把一个简单的 Rust 函数导出到前端页面
• 第二周：理解 WASM 线性内存、JS ↔ WASM 的数据传递模型
• 第三周：尝试 wasmtime + WASI，写一个独立运行的系统工具
• 第四周：结合 AI 推理（candle/WASM）做浏览器端应用

WASM 学习曲线不算陡，但概念密度高。关键是理解"宿主环境"和"沙箱内环境"的边界——哪些是你控制的，哪些是 WASM 运行时控制的。

资料说明

本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0731 资料来源索引，并在发布前将具体来源贴到对应断言之后。