Rust 1.96 + .NET 11 双重地震：WebAssembly 生态正在经历一场"去补丁化"革命

2026年4月，Rust官方博客和.NET团队相继发布重大公告：一个关于链接器的历史遗留补丁将被移除，另一个宣告CoreCLR运行时全面拥抱WASM。这两件事看似独立，实则共同指向一个趋势——WebAssembly生态正在从"能用"走向"规范级可用"，而这背后的代价，是所有Rust WASM开发者都必须面对的一次迁移阵痛。

一、从"临时补丁"说起：--allow-undefined 是什么？

1.1 历史遗留的妥协

要理解这次变更的严重性，得先明白 --allow-undefined 标志在Rust WebAssembly生态里扮演了什么角色。

WebAssembly采用模块化设计，一个WASM模块只能引用在它自己的线性内存空间中定义的符号，以及通过WebAssembly System Interface (WASI) 导入的外部函数。每个导出的函数必须要有明确的实现，每个导入的函数也必须由宿主环境（浏览器、Node.js、Wasmtime等）提供。这是WASM的设计哲学——强隔离、可预测、沙箱安全。

然而，Rust生态在编译WebAssembly目标时，很长一段时间内依赖了一个"不规范"的机制：向链接器 wasm-ld 传递 --allow-undefined 标志。这个标志的作用很直接——允许存在未解析的外部符号引用，不报错，直接放行。

这听起来像是给编译器开了个后门。实际情况也确实如此。这个标志本质上是一个历史妥协，用来处理Rust标准库和部分第三方crate在编译到WASM目标时产生的"悬空引用"问题。

1.2 为什么会有悬空引用？

Rust的编译模型和WASM目标之间存在一个根本性的张力：Rust标准库（std）假设了一个完整的POSIX运行时环境，包括文件系统、网络、进程管理、线程等系统调用。而WASM模块运行在严格的沙箱环境中，理论上根本不应该有这些系统能力的访问权。

为了解决这个矛盾，Rust的WASM编译引入了两个策略：

1. WASI 导入：将标准库的系统调用通过WASI接口导入，由宿主提供实现。
2. --allow-undefined 补丁：对于一些确实无法消解的外部引用，通过链接器标志强制放行，期望运行时通过其他手段（JavaScript胶水层、Host Bindings等）来填补。

第二个策略的隐患在于：它把编译时的错误推迟到了运行时。当一个WASM模块尝试调用一个从未被实现的导入函数时，结果是运行时panic，而不是编译期报错。这是一个巨大的不确定性来源。

1.3 移除后的直接影响

根据 Rust 官方公告（rust-lang/rust#149868），这次变更预计：

• 近期：登陆 nightly 构建版本
• Rust 1.96（2026年5月28日）：随稳定版正式发布

变更内容：Rust编译器将不再自动向 wasm-ld 传递 --allow-undefined 标志。这意味着所有依赖该标志"掩盖"未定义符号的Rust WASM项目，在编译期就会收到链接错误，而非运行时panic。

// 一个典型的"问题代码"——在标准Rust环境下编译通过
// 但在WASM目标下会产生未定义引用
use std::fs;

// 这个函数在WASM环境下本不应该存在
// 之前 --allow-undefined 掩盖了这个问题
pub fn read_config() -> String {
    fs::read_to_string("config.toml").unwrap_or_default()
}

迁移之后，上述代码在 cargo build --target wasm32-unknown-unknown 时会直接报链接错误，而不是在运行时才崩溃。这是一件好事——把错误提前到编译期，正是Rust一贯的设计哲学。

1.4 影响的规模

这个变更的影响面相当广。根据GitHub仓库数据：

• Rust WebAssembly生态中有数千个crate直接依赖WASM目标编译
• wasm-bindgen、wasm-pack、tracing-wasm 等高频使用的工具链都曾间接依赖这一机制
• 使用 wasm32-wasip1（WASI Preview1）和 wasm32-wasip2 目标的项目会受到不同程度的影响

更关键的是，这次变更影响的不仅是Rust项目。任何使用 wasm-ld 进行WASM链接的工具链——包括 Emscripten（通过 wasm-ld）、Clang/LLVM 的WASM后端——都面临类似的"去补丁化"压力。

二、wasm-ld 链接器底层原理：为什么 --allow-undefined 一直能工作？

2.1 wasm-ld 在整个编译链路中的位置

理解这个变更需要了解Rust代码编译到WASM的完整链路：

Source Code (.rs)
    ↓
rustc (前端: 解析、类型检查、LLVM IR生成)
    ↓
LLVM IR 
    ↓
llc (LLVM后端: 生成目标汇编/目标文件)
    ↓
.wasm.o (WebAssembly对象文件)
    ↓
wasm-ld (链接: 合并对象文件 + 处理导入/导出 + 生成最终.wasm)
    ↓
final.wasm (可执行的WASM模块)

wasm-ld 是 LLVM 项目的一部分，扮演"链接器"角色。它接收多个 .wasm.o 文件，将它们合并，解析符号表，处理 import（导入）和 export（导出）指令，生成最终的WASM二进制。

2.2 符号解析与 --allow-undefined 的具体行为

在正常的链接流程中，链接器会构建一个全局符号表：

符号表 (Symbol Table):
  EXPORT: greet() -> section 1
  EXPORT: add(a, b) -> section 3  
  IMPORT: fd_write [env]  -> MUST resolve at runtime
  IMPORT: fd_read [wasi]  -> MUST resolve at runtime

当链接器遇到一个 IMPORT 条目但没有找到对应的提供方时，正常流程会报错。但如果传入了 --allow-undefined，链接器就会将这类未解析引用标记为"延迟绑定"，直接允许生成WASM模块，在运行时由**宿主环境（JavaScript胶水层或Host Runtime）**提供这些符号。

2.3 问题所在：延迟绑定的隐性成本

延迟绑定带来的问题远比表面上看到的严重：

第一，错误从编译期转移到运行时。 编译期报错可以立即修复，运行时panic则可能逃过测试，在生产环境才暴露。

第二，符号缺失没有标准化的兜底机制。 不同宿主环境（浏览器 vs. Wasmtime vs. WASI）处理未定义导入的方式不一致：

• 浏览器环境：抛出 LinkError
• Wasmtime：trap 指令触发
• WASI：可能返回特定错误码或直接崩溃

这导致同一份WASM代码在不同环境下的行为不可预测。

第三，阻碍了WASM工具链的规范化。 WASI标准一直在推进组件模型（Component Model）和 WIT（WebAssembly Interface Types）规范，而 --allow-undefined 机制本质上是在绕过这些规范，用非标准的手段维持一个"凑合能用"的系统。

三、迁移指南：如何在 Rust 1.96 之前做好应对

3.1 立即行动：检测你的项目是否受影响

首先，用最新的 nightly 版本编译你的WASM目标：

# 安装最新的 nightly
rustup update nightly
rustup run nightly rustc --version

# 尝试编译你的WASM目标
cargo +nightly build --target wasm32-unknown-unknown --release 2>&1

如果你看到了类似以下错误，说明你的项目受到了影响：

error: linking with `rust-lld` failed: exit code: 1
  |
  = note:** rust-lld invocation: ... -allow-undefined ...
  = note: wasm-ld: error: unknown symbol: `fd_write`

3.2 常见场景的修复方案

场景一：直接使用了 std::fs、std::net 等POSIX API

这是最常见的问题。Rust标准库的这些模块在WASM目标下本来就不应该使用，因为WASM没有文件系统或网络的概念。

方案：使用条件编译

use std::fs;

#[cfg(not(target_arch = "wasm32"))]
pub fn load_config() -> String {
    fs::read_to_string("config.toml").unwrap_or_default()
}

#[cfg(target_arch = "wasm32")]
pub fn load_config() -> String {
    // WASM环境：从内存或导入获取配置
    String::new()
}

更好的方案：使用特性标志

// lib.rs
[features]
default = []
fs-access = []

[dependencies]
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

pub fn load_config() -> String {
    // 使用特性标志，WASM编译时不会链接fs模块
    // 配置数据可以内嵌、通过JavaScript导入或从IndexedDB读取
    include_str!("config.json")
}

场景二：使用了 tracing 或日志库，但没有配置WASM目标的后端

tracing 是Rust生态中最流行的日志/追踪库。在WASM环境下，tracing-subscriber 需要特殊配置才能工作。

修复：

// 替换 tracing-subscriber 为 wasm-trace
// Cargo.toml
[dependencies]
console_error_panic_hook = "0.1"
web-sys = { version = "0.3", features = ["console"] }
console_error_panic_hook = "0.1"

use web_sys::console;

// WASM专用日志实现
pub fn init_logging() {
    console_error_panic_hook::set_once();
}

场景三：第三方crate导致的链接错误

有些第三方crate在WASM目标下会尝试链接一些平台特有的库。

# 检查具体是哪个符号未定义
cargo +nightly build --target wasm32-unknown-unknown -Z linker-options-whitelist 2>&1 | grep "undefined"

如果是间接依赖（传递依赖）的问题，可能需要：

1. 检查是否有 cfg-if 或条件编译包裹
2. Fork并修复上游crate（推荐先提PR）
3. 使用 cargo tree -i <crate> 定位依赖链

3.3 构建脚本（build.rs）中的注意事项

如果你的项目有 build.rs，需要特别注意：

// build.rs
fn main() {
    // 不要再无条件地链接系统库
    // 改为条件编译
    #[cfg(not(target_arch = "wasm32"))]
    {
        println!("cargo:rustc-cdylib-link-arg=-lm");
    }
    
    // WASM目标下不需要任何系统链接
}

四、.NET 11 Preview 1 的CoreCLR on WASM：另一场底层革命

4.1 从Mono到CoreCLR：WASM上的.NET runtime演进史

如果说Rust的这次变更是"去掉历史补丁"，那么.NET 11 Preview 1在WASM上的CoreCLR集成，则是一场从零到一的底层革命。

长期以来，.NET在WebAssembly上的运行依赖于Mono运行时。Mono是.NET Framework的开源实现，由Xamarin开发维护。2016年微软收购Xamarin后，Mono成为.NET生态的一部分，并在Blazor项目中担任"在浏览器中运行C#"的重任。

Mono的WASM支持本质上是一个嵌入式运行时：Mono VM被编译为WASM模块，然后在WASM沙箱内执行IL（中间语言）字节码。这带来了几个固有问题：

1. 性能开销：IL解释执行 + 垃圾回收都在WASM中，性能远低于原生编译。
2. 体积庞大：Mono Runtime WASM构建非常大（数MB），首屏加载慢。
3. 调试困难：IL级别的调试体验差，源映射支持有限。
4. 功能不完整：部分.NET API在Mono WASM构建中不可用。

4.2 CoreCLR on WASM：真正的AOT原生编译

.NET 11 Preview 1 带来的CoreCLR WebAssembly支持彻底改变了这个局面：

传统方案 (Mono WASM):
  C# Source → Roslyn编译器 → IL字节码 → Mono VM (WASM) → 解释执行
  
CoreCLR WASM方案:
  C# Source → Roslyn编译器 → IL字节码 
      → RyuJIT (AOT) → WASM字节码 → 直接在浏览器引擎执行

CoreCLR on WASM 的核心变化是：使用RyuJIT编译器在编译期生成WASM字节码，而非运行时解释IL。这意味着：

• 性能接近原生：WASM引擎（V8 SpiderMonkey JavaScriptCore）直接执行编译好的WASM字节码，没有IL解释层。
• 体积大幅缩小：不需要嵌入整个VM，只需要运行时支持（GC、线程等），最终产出更小。
• 完整的.NET API：CoreCLR是.NET的"官方" runtime，所有标准库API都是一等公民。

4.3 Blazor的新机会

这个变化对Blazor的影响最为直接。Blazor WebAssembly是.NET在客户端Web开发中的主打方案，目前使用Mono运行时。迁移到CoreCLR后：

性能提升预估（基于.NET团队基准测试）：

（数据来源：.NET 11 Preview 1 发布说明，2026年4月）

开发体验改善：

// CoreCLR WASM下的异步WASM互操作更加顺畅
// 新API：Wasm threading + SIMD完整支持
public class MatrixOps
{
    // 现在可以安全地使用 Span<T> 和硬件加速
    public static double[] Multiply(double[] a, double[] b, int n)
    {
        Span<double> result = stackalloc double[n * n];
        
        // RyuJIT可以为WASM SIMD生成优化的循环
        for (int i = 0; i < n; i++)
            for (int k = 0; k < n; k++)
                for (int j = 0; j < n; j++)
                    result[i * n + j] += a[i * n + k] * b[k * n + j];
        
        return result.ToArray();
    }
}

4.4 技术挑战：GC与WASM沙箱的深度整合

CoreCLR on WASM的最大技术难点在于**垃圾回收器（GC）**与WASM环境的整合。

WASM本身不提供垃圾回收机制——内存是手动的，生命周期由程序员（或编译器/Runtime）管理。CoreCLR的GC（分代式垃圾收集器）在WASM上运行需要解决几个关键问题：

挑战一：GC暂停与WASM执行模型

WASM是单线程顺序执行模型（直到WASM Threads提案引入共享内存多线程）。CoreCLR的GC需要"Stop the World"（STW）暂停来安全地追踪和回收对象。在浏览器环境中，这意味着整个WASM模块的执行都要暂停。

解决方案：.NET团队实现了协作式GC暂停——GC线程通过导入的宿主函数与JavaScript主线程协作，在安全点触发暂停，而非强制中断。这比Mono之前使用的"中断-恢复"模式更精细，对延迟的影响更小。

挑战二：WASM内存管理

CoreCLR的GC假设自己管理内存（malloc/free 风格的托管堆）。WASM的线性内存模型需要适配：

CoreCLR Heap: [Object Header | Fields...] 
                    ↓ 
              Managed Allocator
                    ↓
              WASM Linear Memory (ArrayBuffer)

.NET 11 通过引入 WasmMemory API 解决了这个问题——CoreCLR的托管堆直接映射到WASM的 ArrayBuffer，消除了双重分配的开销。

挑战三：跨语言GC互操作

随着WASM Component Model的推进，未来WASM模块之间需要能互相理解彼此的GC数据结构。CoreCLR on WASM需要实现与WASM GC提案（目前处于第三阶段提案）的对接：

// Rust Wasm GC类型（提案中）
(module
  (gc_type $person (struct (field (ref $string)) (field i32)))
)

// .NET端需要能理解同样的类型表示
// 这是未来跨语言WASM互操作的基础

五、WebAssembly的"去补丁化"全景图：两大生态的交汇点

5.1 为什么会同时发生？

Rust移除 --allow-undefined 和 .NET CoreCLR on WASM 发生在同一个时间窗口，并非巧合。这两件事共同反映了WebAssembly生态进入成熟期的信号：

1. WASM规范自身的完善：WASI标准从Preview1进化到Preview2，再到Component Model；WASM GC提案进入Stage 3；SIMD、Threads等提案逐步稳定。
2. 工具链的规范化压力：当底层规范稳定之后，之前用来"打补丁"的临时方案就成了需要清理的债务。
3. 生产环境的需求：越来越多的企业级应用开始使用WASM，对稳定性、可预测性和性能的要求提高，推动生态从"实验性"走向"生产级"。

5.2 WASM生态的标准化进程

时间线（关键里程碑）:
2019.12  Wasm 1.0 (MVP) 发布
2021.04  WASI Preview1
2022.04  WASI Preview2 (组件模型引入)
2023.11  Wasm GC提案 Stage 3
2024.06  WASI 0.2 (稳定版WASI)
2025.09  Wasm Threads 标准化完成
2026.03  Rust lang/rust#149868 链接器变更
2026.04  .NET 11 Preview1 CoreCLR on WASM
2026.05  Rust 1.96 (预计发布日期)
2026.Q3  Wasm GC 预计进入 Wasm 2.0 提案集

5.3 跨语言WASM互操作的未来

Rust和.NET在WASM层面的同步推进，实际上为跨语言WASM互操作铺平了道路。

WIT（WebAssembly Interface Types）规范允许不同语言编译出的WASM模块以结构化的方式交换数据：

// person.wit
record person {
    name: string,
    age: u32,
    email: option<string>,
}

interface person-store {
    add-person: func(p: person) -> u32;
    get-person: func(id: u32) -> option<person>;
    list-all: func() -> list<person>;
}

world person-app {
    export person-store;
}

有了WIT定义，Rust编译的WASM组件和C#编译的WASM组件可以：

• 互相调用函数
• 共享复合数据类型（结构体、枚举、字符串）
• 在运行时由WASM引擎确保类型安全

这意味着未来的WASM应用可以是多语言的——一个用Rust写核心逻辑，一个用C#写业务层，一个用Go写数据处理，全部编译为WASM组件，通过WIT定义的接口协作。这是WASM最诱人的前景之一。

六、实战：从零构建一个 Rust + .NET 联合 WASM 应用

6.1 场景设计

我们设计一个实际可运行的场景：一个跨语言数据处理管道，Rust负责高性能数值计算，.NET负责业务逻辑编排。

浏览器端
  ├── .NET Blazor (WASM):  UI + 业务编排
  │       └── 调用 Rust WASM 组件进行计算
  └── Rust wasm-bindgen (WASM): 高性能计算核心
          ├── 矩阵运算 (SIMD优化)
          └── 傅里叶变换 (FFT)

6.2 Rust 端：构建WASM计算组件

首先定义 WIT 接口（用于 Rust 和 .NET 之间的类型对齐）：

// compute.wit
interface compute {
    // 矩阵乘法
    mat-multiply: func(a: list<f32>, b: list<f32>, n: u32) -> list<f32>;
    
    // FFT变换
    fft: func(signal: list<complex>, direction: string) -> list<complex>;
    
    // 性能基准测试
    benchmark: func(iterations: u32) -> benchmark-result;
}

record complex {
    real: f32,
    imag: f32,
}

record benchmark-result {
    matrix-ms: f64,
    fft-ms: f64,
    memory-bytes: u64,
}

Rust 端的 WIT 实现：

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

#[wasm_bindgen]
pub fn mat_multiply(a: &[f32], b: &[f32], n: u32) -> Vec<f32> {
    let n = n as usize;
    let mut result = vec![0.0f32; n * n];
    
    for i in 0..n {
        for k in 0..n {
            for j in 0..n {
                result[i * n + j] += a[i * n + k] * b[k * n + j];
            }
        }
    }
    
    result
}

// SIMD优化版本（Rust nightly + target-feature）
#[cfg(target_feature = "simd128")]
pub fn mat_multiply_simd_impl(a: &[f32], b: &[f32], n: usize) -> Vec<f32> {
    // 使用 std::arch::wasm32 的 SIMD  intrinsics
    // 16路并行float32乘法，性能可达普通版的8-16倍
    use std::arch::wasm32::*;
    
    let mut result = vec![0.0f32; n * n];
    
    for i in 0..n {
        for j in 0..n {
            let mut sum = f32x4_splat(0.0);
            let mut k = 0;
            
            while k + 4 <= n {
                let a_vec = f32x4_load(a, i * n + k);
                let b_vec = f32x4_load(b, k * n + j);
                sum = f32x4_add(sum, f32x4_mul(a_vec, b_vec));
                k += 4;
            }
            
            // 处理剩余元素
            let mut acc = [0.0f32; 4];
            f32x4_store(&mut acc, sum);
            for x in acc.iter() { result[i * n + j] += x; }
            while k < n {
                result[i * n + j] += a[i * n + k] * b[k * n + j];
                k += 1;
            }
        }
    }
    
    result
}

6.3 .NET 端：Blazor组件调用WASM

// Pages/ComputeDemo.razor
@page "/compute"
@inject IJSRuntime JS
@using System.Diagnostics

<h3>高性能计算演示</h3>

<div class="card">
    <div class="card-header">矩阵乘法 (1024 x 1024)</div>
    <div class="card-body">
        @if (result is not null)
        {
            <p>计算耗时: <strong>@elapsedMs ms</strong></p>
            <p>首次元素: <strong>@result[0]:F4</strong></p>
        }
        <button class="btn btn-primary" @onclick="RunMatrixBenchmark" disabled="@isRunning">
            @(isRunning ? "计算中..." : "开始计算")
        </button>
    </div>
</div>

@code {
    private IJSObjectReference? wasmModule;
    private bool isRunning;
    private double elapsedMs;
    private float[]? result;
    
    protected override async Task OnInitializedAsync()
    {
        // 加载 Rust 编译的 WASM 模块
        wasmModule = await JS.InvokeAsync<IJSObjectReference>(
            "import", "./_framework/RustCompute.wasm");
    }
    
    private async Task RunMatrixBenchmark()
    {
        if (wasmModule is null) return;
        
        isRunning = true;
        var sw = Stopwatch.StartNew();
        
        try
        {
            // 生成两个 1024x1024 的随机矩阵
            var a = GenerateRandomMatrix(1024);
            var b = GenerateRandomMatrix(1024);
            
            // 调用 Rust WASM 组件
            var resultVec = await wasmModule.InvokeAsync<float[]>(
                "mat_multiply", a, b, 1024);
            
            elapsedMs = sw.Elapsed.TotalMilliseconds;
            result = resultVec;
        }
        catch (Exception ex)
        {
            Console.Error.WriteLine($"计算失败: {ex.Message}");
        }
        finally
        {
            isRunning = false;
        }
    }
    
    private float[] GenerateRandomMatrix(int n)
    {
        var rng = new Random(42); // 确定性种子
        var matrix = new float[n * n];
        for (int i = 0; i < matrix.Length; i++)
            matrix[i] = (float)(rng.NextDouble() * 10);
        return matrix;
    }
}

6.4 构建与部署

# 1. Rust 端构建 WASM 组件
# (需要 wasm32-wasip2 target 和 wit-bindgen)
rustup target add wasm32-wasip2
cargo build --release --target wasm32-wasip2

# 产物: target/wasm32-wasip2/release/rust_compute.wasm

# 2. .NET 端 Blazor 构建
dotnet publish -c Release -o ./publish

# 3. 部署
# 将 Rust WASM 模块复制到 Blazor 的 wwwroot/_framework/
cp target/wasm32-wasip2/release/rust_compute.wasm ./publish/wwwroot/_framework/

七、性能优化的进阶技巧

7.1 Rust WASM 的编译优化

Rust编译到WASM时，有几个关键优化选项：

# Cargo.toml
[profile.release]
opt-level = 3        # 最高优化级别
lto = "thin"         # Thin LTO，平衡编译时间和优化效果
codegen-units = 1    # 单一代码生成单元，允许更多跨模块优化
panic = "abort"      # 移除panic处理代码，减小体积
overflow-checks = false  # 移除溢出检查（生产环境）
strip = true         # 剥离调试信息

[lib]
crate-type = ["cdylib"]  # 编译为C-compatible动态库（最佳WASM导出）

# 关键编译参数
RUSTFLAGS="
  -C target-feature=+simd128,+relaxed-simd
  -C lto=thin
  -C codegen-units=1
" cargo build --release --target wasm32-wasip2

7.2 WASM体积优化的策略

WASM模块体积直接影响加载时间和解析速度。以下是完整的体积优化策略：

使用 wasm-opt

# 安装 binaryen 工具链
brew install binaryen

# 使用 wasm-opt 进行字节码级别优化
wasm-opt -O3 -o output.wasm input.wasm

# 激进优化（可能导致一些罕见情况出错）
wasm-opt -Oz --dce --merge-blocks --remove-unused-module-elements input.wasm

分析体积分布

# 生成详细的体积报告
wasm-opt --print-all -o /dev/null target.wasm 2>&1 | head -50

# 使用 twiggy 分析体积热点
cargo install twiggy
twiggy top target.wasm
twiggy dominator-tree target.wasm

典型Rust WASM的体积分布：

7.3 增量解析与流式加载

对于大型WASM应用，流式编译和增量解析是减少首屏时间的关键：

<!-- 使用 WebAssembly.instantiateStreaming 进行流式加载 -->
<script type="module">
    const response = await fetch('./compute.wasm');
    const { instance } = await WebAssembly.instantiateStreaming(
        response,
        importObject // 包含所有导入函数的对象
    );
    
    // 实例化完成后立即可用，无需等待整个文件下载完毕
    const result = instance.exports.mat_multiply(/* ... */);
</script>

// 在 .NET Blazor 中使用流式编译
// Program.cs
builder.Services.AddBlazorWebAssemblyStreaming();

八、总结：WASM 生态的成熟与程序员的应对之道

8.1 这次变更意味着什么

Rust 1.96 移除 --allow-undefined 和 .NET 11 CoreCLR on WASM，代表了WebAssembly生态走向成熟的两个维度：

• Rust的这次变更：是"清理技术债务"——把为了兼容性而妥协的临时方案去掉，逼迫整个生态走向规范。这对Rust WASM开发者来说是一次短期痛苦、长期受益的迁移。
• .NET的这次变更：是"基础设施升级"——用原生编译（AOT）替换解释执行，用官方runtime替换第三方runtime。这是质的飞跃。

两者共同指向：WebAssembly正在从"能跑就行"走向"生产级可用"。

8.2 对程序员的实际影响

8.3 未来展望：2026-2027年值得关注的WASM进展

1. Wasm GC (WASM 2.0提案集)：将原生GC引入WASM，彻底解决跨语言内存管理问题。Rust的 bort GC框架和 .NET 的 CoreCLR GC 都将受益于此。
2. WASI 0.3：预计引入网络Socket标准化，WASM服务器端应用将获得更完整的系统能力。
3. WASM组件模型普及：多语言协作的WASM应用将从"demo"走向"生产"，生态工具链（wasm-tools、cargo-component）将更加成熟。
4. AI推理WASM化：随着 llama.cpp 的WASM化成熟，浏览器端本地AI推理将成为现实。Rust和ONNX Runtime的WASM构建将在这个领域交汇。

本文信息来源：

• Rust官方博客，2026年4月4日公告（rust-lang/rust#149868）
• .NET 11 Preview 1 发布说明，2026年4月
• WebAssembly官方规范文档：https://webassembly.org / https://wasi.dev
• WASI SDK GitHub Actions Build Log，2026年4月7日

作者：程序员茄子 | 首发于 https://www.chenxutan.com | 未经许可禁止转载