WebAssembly 组件模型与 WASI 深度实战：把「一次编写、到处运行」做成工程现实——从栈式字节码、WIT 接口到 Wasmtime 多语言宿主与 8ms 冷启动的完整指南（2026）

如果你只记住一句话：WebAssembly（WASM）不是「浏览器里的汇编」，而是一套可移植、强隔离、毫秒级启动的二进制计算单元标准；当它配上组件模型（Component Model）与 WASI 系统接口，就从不信任的前端沙箱，进化成了服务端「多语言函数」的通用集装箱。

一、背景介绍：为什么 2026 年我们又在聊 WASM？

「Write once, run anywhere」是IT界被重复宣布过最多次的「即将实现」。Java 用 JVM 宣布过一次，Docker 用容器镜像又宣布过一次，但每一次都带着代价：JVM 需要 200MB 的运行时和秒级的类加载，容器需要 Linux 内核、命名空间和至少几百毫秒的启动。

WebAssembly 的野心更克制，也更危险——它想做**「函数的集装箱」**：

• 一份编译产物，能在浏览器、边缘节点、Linux 服务器、嵌入式芯片上逐字节相同地运行；
• 运行时只有几百 KB 到几 MB，冷启动以毫秒计（实测 Docker + Wasmtime 的 WASI 示例冷启动约 8.2ms，见下文）；
• 默认没有系统调用能力，所有对外部的访问（文件、网络、时钟）都必须由宿主显式授权——这是能力导向安全（capability-based security）的天然实现。

WASM 最初是 2015 年为了把 C/C++ 游戏塞进浏览器而生的（asm.js 的后继者）。但真正让它「溢出」到服务端的，是两条独立的主线在 2024–2026 年的汇合：

1. WASI（WebAssembly System Interface） 把「系统调用」标准化了。早期 WASI Preview 1 只是给 POSIX 的一个瘦封装；WASI Preview 2（2024 末 / 2025 初）引入了组件模型（Component Model），让不同语言编译出的 WASM 模块可以像乐高一样拼装；
2. Wasm 3.0 落地了 64 位线性内存（memory64）、垃圾回收（GC）提案、以及更完整的类型系统，让带 GC 的语言（Java/Kotlin/Go 的部分场景）也能高效跑 WASM。

到 2026 年，WASI 0.3 定稿，补齐了「生产就绪」的最后一公里；Wasmtime 迭代到 40+ 版本（2026 年中已到 45.x）；Docker 原生支持 wasi/wasm32 平台，通过 containerd-wasm-shim-v2 直接调用 Wasmtime 执行。用 The New Stack 的话说：「WASM 正在悄悄普及，而它的『Docker 时刻』可能就在 2026。」

本站前面写过 WebGPU 的深度实战（把浏览器变成 GPU 计算平台），那篇文章讲的是**「把 GPU 当可移植计算资源」；本文讲的是「把任意函数当成可移植、可隔离的计算单元」**——两者是同一叙事的两面，一个管算力，一个管逻辑。

二、核心概念：WASM 到底是什么？

2.1 它不是汇编，是「结构化的栈式字节码」

很多人一听「字节码」就以为是汇编。错了。WASM 是一种结构化的、基于栈的虚拟指令集（structured stack machine）。它的设计目标里，「可验证的安全性」和「紧凑的体积」排在「执行速度」前面。

一个最简单的函数——两个整数相加——用 WAT（WebAssembly Text format，人类可读的文本形式）写出来是这样的：

(module
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add)
  (export "add" (func $add)))

注意它的执行模型：

1. local.get $a 把局部变量 a 压入操作数栈；
2. local.get $b 把 b 也压栈；
3. i32.add 从栈顶弹出两个 i32，相加，把结果压回栈顶；
4. 函数的 result i32 取栈顶作为返回值。

没有任何寄存器、没有跳转到任意地址的能力、没有「指针算术」（在 WASM 自己的世界里）。所有控制流都是结构化的——block / loop / if / br 都是带作用域的，不允许 goto 到任意偏移。这意味着：一个 WASM 模块可以在不执行它的情况下，通过静态扫描就证明「它不会越界访问内存、不会陷入死循环之外的非法状态」。这就是它能被安全地放进浏览器沙箱、放进不可信插件系统的根本原因。

顺手把递归版的阶乘也写出来，体会一下结构化控制流（loop + br_if）：

(module
  (func $fac (param $n i32) (result i32)
    (local $acc i32)
    (local.set $acc (i32.const 1))
    (block $done
      (loop $cont
        ;; 如果 n <= 1 就跳出
        (br_if $done (i32.le_s (local.get $n) (i32.const 1)))
        (local.set $acc (i32.mul (local.get $acc) (local.get $n)))
        (local.set $n (i32.sub (local.get $n) (i32.const 1)))
        (br $cont)))
    (local.get $acc))
  (export "fac" (func $fac)))

把 WAT 编译成二进制只需要官方工具链：

# 安装 wabt 工具集
brew install wabt            # macOS
wat2wasm fac.wat -o fac.wasm # 文本 -> 二进制
wasm2wat fac.wasm            # 二进制 -> 文本（验证）

fac.wasm 只有几十字节。这就是 WASM「紧凑」的直观体现：一份等价于几百行机器码的逻辑，体积可以压缩到几十字节。

2.2 模块（Module）、实例（Instance）与宿主（Host）

这三个词是理解 WASM 运行时模型的钥匙：

• Module（模块）：编译后的 .wasm 二进制，是「代码蓝图」，本身不可执行、不可变、可共享。类似于「类」或「ELF 文件」。
• Instance（实例）：把一个 Module 实例化（分配线性内存、全局变量、表）后得到的「运行态对象」。一个 Module 可以实例化出多个独立的 Instance，彼此内存隔离。类似于「对象 / 进程镜像」。
• Host（宿主）：运行 WASM 的外部环境（浏览器、Wasmtime、你的 Rust 程序、Docker）。宿主拥有全部权力：它决定给实例多少内存、给它接入哪些外部函数（导入）、以及何时中断它。

这是 WASM 安全模型的枢纽：WASM 模块自己什么都干不了。想读写文件？得宿主「导入」一个文件读写函数给你。想联网？得宿主导入网络接口。模块能做的事，严格等于宿主授权的事。这种「默认零权限」正是它区别于普通原生代码的地方。

2.3 四大支柱与一个反直觉的事实

反直觉的事实：WASM 通常比原生机器码慢。它的安全边界（边界检查、无共享内存破坏）要付出代价，典型场景下比等效原生代码慢 1.1x–2x。那它凭什么流行？因为它解决的是**「隔离 + 可移植 + 启动速度」这个三元组**，而不是「绝对性能」。在需要跑大量短命、多租户、不可信函数的场景（插件系统、边缘函数、Serverless、多语言库分发），这一组合拳目前没有对手。

三、架构分析：组件模型、WASI 与运行时栈

3.1 字节码联盟与 Cranelift

WASM 生态的「内核」是 字节码联盟（Bytecode Alliance），由 Mozilla、Fastly、Intel、Red Hat 等共同发起。它维护两样东西：

• Cranelift：一个模块化的代码生成后端。Wasmtime 默认用 Cranelift 把 WASM 字节码 JIT 编译成本地机器码。它不像 LLVM 那么重，启动快、编译快，专为 WASM 这类「小而多」的编译单元优化。
• Wasmtime：字节码联盟官方的高性能 WASM/WASI 运行时，既能在命令行跑，也能作为库嵌入到任何语言（Rust/Go/C/Python/.NET）里。

运行时不止 Wasmtime 一个。还有：

• Wasmer：早期最流行的运行时，支持 Cranelift / LLVM / 自研后端切换；
• Wasm3：纯解释器，体积极小（~100KB），适合嵌入式；
• V8（Chrome）/ SpiderMonkey（Firefox）：浏览器内置的运行时。

选型直觉：要嵌入到自己的服务里 → Wasmtime；要塞进 IoT / 嵌入式 → Wasm3；要浏览器里的逻辑 → 浏览器自带。

3.2 WASI：从「瘦 POSIX 封装」到「能力导向系统接口」

早期 WASI Preview 1 本质上是「给 WASM 一个能用的 POSIX 子集」。问题是 POSIX 本身是「全局可见」的：你 open("/etc/passwd") 就能读，权限靠操作系统的事后检查。这跟 WASM 的「默认零权限」哲学冲突。

WASI Preview 2 的革命性在于引入了组件模型 + 能力导向（capability-based）语义：

• 文件系统访问不再是「全局 open 路径」，而是宿主预先给你一个目录句柄（descriptor），你只能在这个句柄上操作。拿不到句柄，就读不到任何文件。
• 网络同理：宿主给你一个 outgoing-handler，你只能往它允许的地址发请求。
• 时钟、随机数、环境变量，全部是「宿主显式注入」的对象。

这套设计与浏览器一脉相承：网页 JS 也没有 open()，只能通过宿主给的 fetch、localStorage 等受限接口做事。WASM 把这套哲学带到了服务端。

3.3 组件模型（Component Model）与 WIT

这是 2026 年 WASM 最值得关注的东西，没有之一。

问题：传统 WASM 模块之间、WASM 与宿主之间，靠的是「线性内存 + 一堆导入导出函数」来通信。传个字符串？得手动在共享内存里写指针和长度，两边约定 ABI，脆弱且易错。这就是所谓的「wasm 接口类型（interface types）」想解决的事。

组件模型的解法：引入一个更高层的抽象——组件（Component）。一个组件可以包含并组合多个模块，对外暴露用 WIT（WebAssembly Interface Type） 描述的强类型接口。WIT 支持 record、enum、variant、list、string、result 等高级类型，并且定义了 Canonical ABI——一套标准化的内存布局规则，保证「用 Rust 写的组件」和「用 Go 写的组件」能零拷贝地互相传一个 record。

一个最小的 WIT 定义长这样：

package example:greet@0.1.0;

interface greeter {
    /// 向某人问好
    greet: func(name: string) -> string;
}

world app {
    export greeter;
}

它的意思是：我这个组件**导出（export）**一个 greeter 接口，里面有个 greet 函数，吃一个字符串、吐一个字符串。

然后用 Rust 实现它（借助 wit-bindgen 或 cargo-component）：

// src/lib.rs
use example::greet::Greeter;

struct Component;

impl Greeter for Component {
    fn greet(name: String) -> String {
        format!("Hello, {name}! 来自一个被沙箱化的 WASM 组件。")
    }
}

// 把 Component 作为 greeter 接口导出
example::greet::export!(Component with_types_in example::greet);

构建时不再是 cargo build --target wasm32-unknown-unknown 那种裸模块，而是：

# 安装 cargo-component（WASM 组件的一站式构建器）
cargo install cargo-component
cargo component build --release
# 产物：target/wasm32-wasip2/release/greet.wasm （一个标准组件）

这一步的意义被严重低估：你现在可以用 Rust 写一部分、用 Go 写一部分、用 C 写一部分，把它们编译成 WASM 组件，然后在编译期就拼装成一个单一的可执行组件，类型安全、零粘合代码、跨语言。这相当于把「微服务拆分」下沉到了「函数级别」，而且没有序列化/网络开销。

3.4 WASM 与容器的关系：不是替代，是补位

一个常见误解是「WASM 要取代 Docker」。准确的说法是：WASM 补上了容器不擅长的场景。

• 容器的最小隔离单位是「进程 + 命名空间 + 内核」，启动要初始化整个 Linux 用户态，冷启动 100ms–数秒；
• WASM 的隔离单位是「实例 + 线性内存」，启动是内存分配级的，冷启动个位数毫秒。

Docker 在 2026 年已经原生支持了 WASM：

# 下载一个标准 WASI hello 示例（无需 Dockerfile）
curl -sLO https://github.com/WebAssembly/WASI/releases/download/snapshot-24/wasi-hello.wasm

# 直接以 wasi/wasm32 平台运行 —— 跳过 buildkit、layer 解压、命名空间初始化
docker run --rm -i --platform=wasi/wasm32 docker.io/library/wasi:latest /wasi-hello.wasm
# 输出：Hello, world!

背后是 containerd-wasm-shim-v2 拦截了 wasi/wasm32 平台请求，直接交给 Wasmtime 执行。实测冷启动约 8.2ms（Intel Xeon Platinum 8480C）。对高密度、短生命周期、多租户的函数负载（边缘函数、AI 推理预处理、规则引擎），这是数量级的优势。

但 WASM 不适合需要完整操作系统语义的工作负载：长连接数据库代理、需要 io_uring/eBPF 等内核特性的程序、重度多线程共享内存的场景。本站前面写过的 eBPF 深度实战、Kubernetes 控制平面，这些恰恰该留在容器/原生里。

四、代码实战：从手写字节码到多语言宿主嵌入

下面用四个递进的例子，把前面的概念落地。

4.1 手写 WAT 并直接跑（理解栈式机）

我们已经写了 fac.wat。用 Wasmtime 直接运行它：

# 安装 wasmtime（macOS）
curl https://wasmtime.dev/install.sh -sSf | bash

# 运行
wasmtime fac.wasm --invoke fac 5
# 输出：120

wasmtime fac.wasm --invoke fac 5 等价于：加载模块 → 实例化 → 找到导出函数 fac → 压入参数 5 → 执行 → 取返回值。你刚才手写的几十字节二进制，被一个工业级 JIT 编译成了原生机器码执行。

4.2 Rust 编译成 WASM 模块（无 WASI，纯计算）

最常见的「从语言到 WASM」路径。假设你想把一段高性能的图像/算法逻辑用 Rust 写、在浏览器或 Node 里调用：

# Cargo.toml
[package]
name = "wasm-demo"
version = "0.1.0"

[lib]
crate-type = ["cdylib"]   # 关键：编译成 C 兼容的动态库，再转 wasm

[dependencies]
wasm-bindgen = "0.2"

// src/lib.rs
use wasm_bindgen::prelude::*;

/// 计算斐波那契数列第 n 项（故意用朴素递归，只为演示）
#[wasm_bindgen]
pub fn fib(n: u32) -> u32 {
    match n {
        0 => 0,
        1 => 1,
        _ => fib(n - 1) + fib(n - 2),
    }
}

/// 一个带内存操作的例子：把输入数组每个元素乘以 2
#[wasm_bindgen]
pub fn double_slice(input: &[u32]) -> Vec<u32> {
    input.iter().map(|x| x * 2).collect()
}

构建与优化：

rustup target add wasm32-unknown-unknown
cargo build --release --target wasm32-unknown-unknown

# 用 wasm-opt（Binaryen）进一步瘦身/优化
wasm-opt -Oz -o pkg/opt.wasm target/wasm32-unknown-unknown/release/wasm_demo.wasm

double_slice 这个例子值得停下来想一下：&[u32] 和 Vec<u32> 是 Rust 的高级类型，但 WASM 线性内存里只有「一块字节」。wasm-bindgen 在这里干了重活——它自动生成 JS 胶水代码，在 JS 的 Array 和 WASM 的线性内存之间做编组（marshalling）。而组件模型 + WIT 想消灭的，恰恰就是这层手工/半自动胶水：在组件世界里，类型通过 Canonical ABI 直接对接，不需要 wasm-bindgen。

4.3 构建一个标准 WASI 组件（WIT + Rust）

回到 3.3 的 greet 组件。完整工程结构：

greet-component/
├── Cargo.toml
├── wit/
│   └── world.wit          # 就是前面那段 WIT
└── src/
    └── lib.rs             # 前面的 Rust 实现

# Cargo.toml
[package]
name = "greet-component"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
wit-bindgen = { version = "0.30", features = ["realloc"] }

构建并运行：

cargo component build --release
# 产物：target/wasm32-wasip2/release/greet_component.wasm

# 用 wasmtime 直接调用组件的导出接口
wasmtime target/wasm32-wasip2/release/greet_component.wasm \
  --invoke greet '{"name": "程序员茄子"}'
# 输出：Hello, 程序员茄子! 来自一个被沙箱化的 WASM 组件。

注意 --invoke greet 后面那串 JSON：因为 greet 的参数在 WIT 里是强类型 string，Wasmtime 能在命令行用 JSON 表达复杂入参。这就是组件模型带来的「接口即契约」体验。

4.4 在 Rust 中嵌入 Wasmtime，跑不可信插件

这是 WASM 最实用的服务端场景：你的主程序用 Rust/Go 写，允许用户用任何语言写插件，编译成 WASM 丢进来运行，你保证它伤不了主进程。

宿主侧（Rust + Wasmtime，WASI 接入）：

use anyhow::Result;
use wasmtime::{Engine, Store, Module, Linker, Instance};
use wasmtime_wasi::{WasiCtx, WasiCtxBuilder, WasiView};

// 宿主状态：持有一个 WASI 上下文
struct HostState {
    wasi: WasiCtx,
}
impl WasiView for HostState {
    fn ctx(&mut self) -> &mut WasiCtx {
        &mut self.wasi
    }
}

fn run_plugin(path: &str) -> Result<()> {
    // 1. 创建引擎（默认用 Cranelift JIT）
    let engine = Engine::default();

    // 2. 建立 linker，并把 WASI 接口「链接」进宿主
    //    这样插件里的 console/文件/网络调用会路由到我们授权的 WASI 实现
    let mut linker: Linker<HostState> = Linker::new(&engine);
    wasmtime_wasi::add_to_linker(&mut linker, |state: &mut HostState| state)?;

    // 3. 构建宿主状态：只 inherit 标准输入输出，不暴露任何真实文件系统
    let mut store = Store::new(
        &engine,
        HostState {
            wasi: WasiCtxBuilder::new()
                .inherit_stdout()   // 允许写 stdout
                .inherit_stderr()
                .build(),
        },
    );

    // 4. 加载并实例化不可信插件
    let module = Module::from_file(&engine, path)?;
    let instance: Instance = linker.instantiate(&mut store, &module)?;

    // 5. 调用插件的导出入口（WASI 命令式组件约定入口为 _start）
    let main = instance.get_typed_func::<(), ()>(&mut store, "_start")?;
    main.call(&mut store, ())?;

    Ok(())
}

fn main() -> Result<()> {
    // 这个插件即使内部想读 /etc/passwd，也因为宿主没给文件句柄而直接报错
    run_plugin("untrusted-plugin.wasm")
}

关键点：我们故意没有 .inherit_stdio() 之外的任何文件系统或网络授权。那个 untrusted-plugin.wasm 哪怕恶意，也只能在「写 stdout + 用光自己线性内存」的范围内搞破坏——它碰不到主进程内存、碰不到宿主磁盘、碰不到网络。这就是能力导向安全的工程落地。

4.5 在 Go 中嵌入 Wasmtime

WASM 的「多语言宿主」不是说说而已。同一份插件，也能嵌进 Go 服务（字节码联盟官方的 wasmtime-go，2026 年中已到 45.x）：

package main

import (
    "context"
    "fmt"
    "github.com/bytecodealliance/wasmtime-go/v45"
)

func main() {
    engine := wasmtime.NewEngine()
    module, err := wasmtime.NewModuleFromFile(engine, "add.wasm")
    if err != nil {
        panic(err)
    }

    store := wasmtime.NewStore(engine)
    // 链接 WASI（生产环境应配置受限的 wasi 上下文）
    linker := wasmtime.NewLinker(engine)
    wasmtime_wasi.NewWasi(linker, store)

    instance, err := linker.Instantiate(store, module)
    if err != nil {
        panic(err)
    }

    add := instance.GetFunc(store, "add")
    result, err := add.Call(store, 40, 2)
    if err != nil {
        panic(err)
    }
    fmt.Println("40 + 2 =", result.(int32)) // 42
}

看到没有：「用 Rust 写的插件」和「用 Go 写的主程序」通过同一份 .wasm 契约对接，双方都不需要为对方改语言、不需要 gRPC、不需要序列化协议。组件模型把这个故事从「能跑」推向「类型安全、可组合、可分发」。

五、性能优化：让你的 WASM 又快又小

WASM 默认不是最快的，但它是**最可被优化到「刚好够用」**的格式。几条实战经验：

5.1 编译策略：AOT / JIT / 解释器三选一

Wasmtime 支持多种执行模式：

生产建议：用 AOT 把核心组件预编译成 .cwasm，这样运行时连 JIT 编译的毫秒开销都省了，冷启动进一步压到最低。

wasmtime compile greet_component.wasm -o greet.cwasm
wasmtime greet.cwasm --invoke greet '{"name":"AOT"}'

5.2 体积优化：wasm-opt + 编译参数

WASM 体积小，但你还能更小：

# Cargo.toml 的 [profile.release]
[profile.release]
opt-level = "z"          # 优化体积而非速度（边缘场景常用）
lto = true               # 链接时优化，跨 crate 内联
strip = "debuginfo"      # 去掉调试信息
codegen-units = 1        # 单代码生成单元，更好的内联

# 用 Binaryen 的 wasm-opt 做后处理
wasm-opt -Oz -o out.wasm in.wasm

对 wasi-preview1-component-adapter 这类胶水适配层也单独设 opt-level = "s"，整体能再砍掉可观体积。

5.3 启动优化：实例化成本与内存快照

WASM 启动主要花在两处：（1）编译/JIT 模块，（2）实例化（分配线性内存、初始化全局变量）。

• 解决（1）：AOT 预编译 + 模块缓存（Wasmtime 有编译缓存目录，可配置 [cache] 段）。
• 解决（2）：内存快照（snapshotting）/ 实例池（pooling）。对高频短命负载，维护一个「预热好的实例池」，请求来了直接从池里取一个、重置状态、用、归还。Wasmtime 提供 PoolingAllocationStrategy，可在 Store 配置里开启，把「每次新建实例」变成「复用预分配槽位」，把实例化开销降到几乎为零。

5.4 一个直观的密度对比

对「每秒成千上万次、每次几毫秒」的函数负载：

• 容器（冷启动 ~200ms+，内存 ~50–100MB/实例）：一台 8GB 机器大约跑几十到一百个隔离实例；
• WASM（冷启动 ~8ms，内存 ~几 MB/实例，配合实例池可亚毫秒复用）：同一台机器能跑成千上万个隔离实例。

这就是为什么 Cloudflare Workers、Fastly Compute、Fermyon Spin 这类边缘计算平台全部押注 WASM——不是因为它绝对快，而是因为它在「隔离 + 密度 + 启动」这个三角上无解地优。

六、总结与展望：WASM 适合你吗？

适合引入 WASM 的信号

• 你要跑不可信/第三方代码（插件系统、规则引擎、用户自定义函数）——WASM 的零权限沙箱是杀手锏；
• 你需要高密度、短生命周期的计算单元（边缘函数、Serverless、AI 推理的前/后处理）；
• 你有多语言团队，想复用同一份算法逻辑而不重写（Rust 写核心，Go/JS/Python 调用）；
• 你需要确定性的执行环境（区块链智能合约、可复现计算）。

暂时别用 WASM 的场景

• 需要完整 OS 语义、长连接、内核特性的后台服务（留在容器/原生）；
• 团队还没有「组件模型 + WIT」的工程经验，且收益不明显（别为了用而用）；
• 对绝对单核性能极度敏感、且无法接受 1.x 倍开销的热路径（先用原生）。

2026 年的判断

组件模型已经从「提案」走向「可用」，WASI 0.3 定稿补上了生产就绪的最后一块拼图；Wasmtime 45.x、Docker 原生 WASM、Fermyon Spin / Cosmonic 等平台把「写组件 → 部署」的链路打通。它还没到「Docker 时刻」那种全民化拐点——WIT 的工具链心智负担、组件间组合的调试体验、以及「到底该用 WASM 还是容器」的决策成本，仍是真实门槛。

但方向是清楚的：未来几年，「函数」会成为新的部署单元。你写的不再是一个微服务、一个容器，而是一个个强类型、可组合、跑在哪都一样的 WASM 组件。当那一天到来，今天理解栈式字节码、WIT 接口和 Wasmtime 嵌入的人，会像 2014 年早期理解容器的人一样，站在浪潮前面。

呼应一下本站的相邻文章：想看「浏览器里跑 GPU 计算」去读 WebGPU 实战；想看「内核级可观测性」去读 eBPF 实战；想看「云原生操作系统」去读 Kubernetes 深度拆解。本文补上的，是那块把「逻辑」本身变成可移植、可隔离、可组合单元的地基——WebAssembly。

动手建议：今天就从 cargo component new greet 起步，写一个会 greet 的组件，用 wasmtime 跑起来。当你亲眼看到 Rust 写的函数被一个工业级运行时在毫秒级沙箱里执行，你会理解为什么我们说——WebAssembly 不是又一个玩具，它是「一次编写、到处运行」最接近工程现实的一次。

参考资料（均为公开可查的 2025–2026 资料）：Bytecode Alliance 官方文档与 Wasmtime 仓库、WASI Preview 2 / 0.3 规范说明、WebAssembly 3.0 提案进展、Docker wasi/wasm32 平台与 containerd-wasm-shim-v2 实测数据、The New Stack / InfoQ 中文站关于「WASI 1.0 与 2026 普及」的报道。文中冷启动 8.2ms 为 Docker + Wasmtime 在 Intel Xeon Platinum 8480C 上的公开实测值。