WASM 跨语言互操作的坑：字符串编码、内存管理和异步调用的三座大山

一、"Hello, 世界" 花了三个小时

去年我尝试让 Rust 编译的 WASM 模块在 Node.js 里跑。第一个测试：传一个字符串进去，让它返回 "Hello, " + 输入。

我以为一行wasm_bindgen就搞定了。结果遇到了三个问题：

1. Rust 的&str在 WASM 里变成了一对(ptr, len)—— 但我不知道这个ptr指向的是 WASM 的线性内存还是 JS 的堆。
2. 中文字符 "你好" 在 Rust 端变成了ä½ å¥½—— UTF-8 和 JS 的 UTF-16 之间的编码地狱。
3. 把返回值传回 JS 时，WASM 模块已经free了那块内存 —— JS 拿到的是一块悬垂指针。

一个 "Hello World" 级别的测试，我折腾了三个小时。这就是 WASM 跨语言互操作的现实。

二、三座大山全景

三、字符串编码与内存管理

为什么 Rust 的&str在 JS 端是(ptr, len)而不是字符串？

WASM 模块内部有一块线性内存——本质上是一个Vec<u8>。Rust 的一切数据（字符串、结构体、数组）都存在这块内存里。JS 要想读这个数据，只能通过一个ptr（偏移量）+len来定位。

/// Rust 侧：导出一个接受字符串的函数 #[wasm_bindgen] pub fn greet(name: &str) -> String { format!("Hello, {}!", name) } // wasm-bindgen 做了什么？ // 1. JS 调用时，把 JS 字符串编码为 UTF-8 字节 // 2. 把字节拷贝到 WASM 线性内存中 // 3. 把 (ptr, len) 传给 Rust // 4. Rust 端用 (ptr, len) 构造 &str（零拷贝 —— 直接指向 WASM 内存） // 5. 返回时，wasm-bindgen 把 String 的字节拷贝回 JS // 然后 free WASM 侧的内存

坑 1A：编码的无声转换

/// ❌ Rust 里跑得好好的，到 JS 就乱码了 #[wasm_bindgen] pub fn process_text(input: &str) -> String { // input 是 UTF-8 编码的 Rust 字符串 let chars: Vec<char> = input.chars().collect(); // 某些 emoji 在 JS 端可能是两个 UTF-16 码元（surrogate pair） // 但在 Rust 端是一个 char // 这意味着字符串长度在两边可能不同！ format!("处理了 {} 个字符", chars.len()) } /// ✅ 解决方案：明确编码转换 #[wasm_bindgen] pub fn process_text_safe(input: &str) -> String { // 方法 1：显式处理为 UTF-16 长度（和 JS 的 .length 一致） let utf16_len = input.encode_utf16().count(); format!("UTF-8 字符数: {}, UTF-16 码元数: {}", input.chars().count(), utf16_len) // ^^ Rust 视角 ^^ JS 视角 } /// ✅ 传递二进制数据时，用 Vec<u8> 而非 String #[wasm_bindgen] pub fn process_binary(data: &[u8]) -> Vec<u8> { // &[u8] 在 JS 端映射为 Uint8Array // 避免了字符串编码问题 data.to_vec() }

坑 1B：零拷贝的隐藏代价

wasm-bindgen的零拷贝看起来很美好——JS 传进来的字符串不需要拷贝。但实际上：

/// ⚠️ 零拷贝意味着 JS 的字符串在 WASM 内存里存在 /// 但这块内存的"所有权"在 WASM 侧 /// 如果 JS 侧在 GC 时回收了原始字符串，WASM 侧的 &str 不会受影响 /// 因为字节已经拷贝到 WASM 线性内存了 /// 真正需要关心的是返回值的生命周期 #[wasm_bindgen] pub fn get_config_key(key: &str) -> &str { // ❌ 不能返回对局部变量的引用！ let value = CONFIG.get(key).unwrap_or("unknown"); value // 这个引用的生命周期不够长 } /// ✅ 返回 String，让 wasm-bindgen 负责拷贝和释放 #[wasm_bindgen] pub fn get_config_key_owned(key: &str) -> String { CONFIG.get(key).unwrap_or("unknown").to_string() // ^^^ String 的所有权转移给 wasm-bindgen // 它会把字节拷回 JS，然后释放 WASM 侧的内存 }

第二座大山：内存管理

坑 2A：谁分配，谁释放 —— 跨语言的所有权问题

/// ❌ 内存泄漏的经典场景 #[wasm_bindgen] pub struct DataBuffer { data: Vec<u8>, } #[wasm_bindgen] impl DataBuffer { /// 创建一个 DataBuffer，在 WASM 内存里分配空间 pub fn new(size: usize) -> DataBuffer { DataBuffer { data: vec![0u8; size], } } /// 返回数据的指针，JS 端可以直接操作 WASM 内存 pub fn as_ptr(&self) -> *const u8 { self.data.as_ptr() } // ⚠️ 问题：没有释放方法！ // JS 端调用 new() 后，如果不主动释放，内存永远收不回 } /// ✅ 显式释放 + Drop 实现 #[wasm_bindgen] impl DataBuffer { /// JS 必须调用这个来释放 pub fn free(self) { // self 被消耗，drop 自动释放 data // 这是 Rust 的 RAII 在起作用 —— 但需要 JS 配合 } } // 最佳实践：在 JS 包装类里自动管理 // class DataBuffer { // constructor(size) { // this.inner = wasm.DataBuffer.new(size); // } // // 用 FinalizationRegistry 或显式 dispose 来释放 // dispose() { this.inner.free(); } // }

坑 2B：跨语言生命周期 —— 指针悬垂问题

/// ❌ 这是 WASM 里最危险的一类 bug #[wasm_bindgen] pub fn get_data_slice(buffer: &DataBuffer) -> &[u8] { &buffer.data[..10] // 返回 WASM 内存中的引用 } // JS 侧： // const buffer = DataBuffer.new(1024); // const slice = wasm.get_data_slice(buffer); // 拿到 WASM 内存的指针 // buffer.free(); // 释放了！ // console.log(slice); // ← 悬垂指针！读的是已释放的内存 // // 在某些 JS 引擎上直接崩溃，在另一些上返回垃圾数据 /// ✅ 修复方案 1：返回拷贝，不返回引用 #[wasm_bindgen] pub fn get_data_copy(buffer: &DataBuffer) -> Vec<u8> { buffer.data[..10].to_vec() // 拷贝到 JS 可访问的堆内存 } /// ✅ 修复方案 2：如果必须返回引用，用 JsValue 包装指针+长度 /// 但 JS 端必须承诺在 buffer 释放前使用 slice #[wasm_bindgen] pub struct DataSlice<'a> { // 显式生命期绑定，编译器帮你检查 _buffer: &'a DataBuffer, offset: usize, len: usize, }

坑 2C：检测内存泄漏

/// ✅ WASM 内存使用监控 #[wasm_bindgen] pub fn wasm_memory_stats() -> JsValue { let stats = serde_json::json!({ "total_allocated": wasm_allocated_bytes(), "active_objects": ACTIVE_OBJECTS.load(Ordering::Relaxed), }); JsValue::from_str(&stats.to_string()) } // 在 JS 侧定期调用： // setInterval(() => { // const stats = JSON.parse(wasm.wasm_memory_stats()); // if (stats.total_allocated > 100_000_000) { // console.warn("WASM 内存使用超过 100MB:", stats); // } // }, 10000);

四、异步调用与跨语言实战

坑 3A：Promise 与 Future 的桥接

/// ❌ 最简单的异步函数，但背后有一整个桥接层 #[wasm_bindgen] pub async fn fetch_and_process(url: &str) -> Result<String, JsValue> { // 这个 async fn 背后发生了什么？ // 1. wasm-bindgen 把 Future 注册到 JS 的 Promise 系统 // 2. 内部的 await 操作被编译为 WASM 的暂停/恢复机制 // 3. 每个 .await 点都可能让出控制权给 JS 事件循环 let response = reqwest::get(url).await.map_err(|e| { JsValue::from_str(&format!("请求失败: {}", e)) })?; let text = response.text().await.map_err(|e| { JsValue::from_str(&format!("读取响应失败: {}", e)) })?; Ok(text) } // JS 侧调用： // const result = await wasm.fetch_and_process("https://api.example.com/data");

关键限制：WASM 的 Rust async 依赖于wasm-bindgen-futures提供的基础设施。在单线程 WASM 环境中（如没有 SharedArrayBuffer 的 Safari），所有异步操作实际上是协作式多任务——一个 Future 必须主动.await其他 Future 才能推进。

/// ❌ 在 WASM 里做同步 sleep —— 会冻结整个页面 #[wasm_bindgen] pub fn heavy_work() { std::thread::sleep(Duration::from_secs(5)); // 阻塞了 JS 主线程！ } /// ✅ 异步等待，不阻塞事件循环 #[wasm_bindgen] pub async fn heavy_work_async() { // 使用 wasm-bindgen-futures 的 sleep wasm_bindgen_futures::JsFuture::from( js_sys::Promise::new(&mut |resolve, _| { web_sys::window() .unwrap() .set_timeout_with_callback_and_timeout_and_arguments_0( &resolve, 5000, ) .unwrap(); }) ).await.unwrap(); }

坑 3B：从 JS 回调到 Rust Future

/// WASM 里处理 JS 事件 = 把回调用 Promise 包装 = 声明式写法 use wasm_bindgen::prelude::*; use wasm_bindgen_futures::JsFuture; /// ✅ 把浏览器的 EventListener 变成 Rust 的 Future #[wasm_bindgen] pub async fn wait_for_click() -> Result<(), JsValue> { let window = web_sys::window().unwrap(); let document = window.document().unwrap(); let promise = js_sys::Promise::new(&mut |resolve, _reject| { let callback = Closure::once(move || { resolve.call0(&JsValue::NULL).unwrap(); }); document.add_event_listener_with_callback( "click", callback.as_ref().unchecked_ref(), ).unwrap(); // ⚠️ 注意：callback 可能永远不会被调用 // 如果用户不点击，这个 Future 永远 pending // 需要加超时机制 callback.forget(); // 让 JS 持有 callback，避免被 GC }); // 加一个 30 秒超时 tokio::select! { _ = JsFuture::from(promise) => { Ok(()) } _ = wasm_bindgen_futures::JsFuture::from( js_sys::Promise::new(&mut |resolve, _| { web_sys::window().unwrap() .set_timeout_with_callback_and_timeout_and_arguments_0( &resolve, 30_000 ).unwrap(); }) ) => { Err(JsValue::from_str("等待点击超时")) } } }

实战：跨语言调用的完整方案

把这些坑整合起来，一套可用的跨语言调用模式：

/// ✅ 模式 1：简单数据传递 —— 让 wasm-bindgen 自动处理 #[wasm_bindgen] pub fn compute(data: &[f64]) -> Vec<f64> { // 输入：JS Float64Array → WASM &[f64] (零拷贝) // 输出：WASM Vec<f64> → JS Float64Array (拷贝) data.iter().map(|x| x * x + 1.0).collect() } /// ✅ 模式 2：复杂数据 —— 用 serde JSON 序列化 #[wasm_bindgen] pub fn process_json(input: &str) -> String { let parsed: Request = serde_json::from_str(input).unwrap(); let response = Response { result: parsed.data * 2, message: "处理完成".to_string(), }; serde_json::to_string(&response).unwrap() } /// ✅ 模式 3：长生命周期对象 —— 传 handle #[wasm_bindgen] pub struct ModelHandle(u32); // 轻量级的 ID #[wasm_bindgen] pub fn load_model(data: &[u8]) -> ModelHandle { let model = Model::from_bytes(data); let id = GLOBAL_MODELS.lock().unwrap().insert(model); ModelHandle(id) } #[wasm_bindgen] pub fn run_model(handle: &ModelHandle, input: &[f64]) -> Vec<f64> { let models = GLOBAL_MODELS.lock().unwrap(); let model = models.get(handle.0).unwrap(); model.run(input) } #[wasm_bindgen] pub fn free_model(handle: ModelHandle) { GLOBAL_MODELS.lock().unwrap().remove(handle.0); }

实操案例：用 FinalizationRegistry 防 WASM 内存泄漏

我写了一个在浏览器里做图片压缩的 WASM 模块。核心逻辑是把 JS 的ImageData传给 Rust，在 WASM 侧用imagecrate 做压缩，再把压缩后的Vec<u8>传回 JS。功能一天就写完了，但跑了几天后发现浏览器 tab 的内存从 80MB 慢慢涨到了 500MB——每次压缩都泄漏一小块内存。

排查过程很痛苦。WASM 线性内存的分配和释放对 JS 来说是不透明的，DevTools的 Memory profiler 只能看到 "WASM 内存" 作为一个整体在涨。我在 Rust 侧加了一个全局计数器ALLOCATED_BYTES: AtomicUsize，每次Vec::new时加，每次drop时减。然后发现计数器只涨不减——原来drop根本没被调用。

根因是我在 Rust 侧把压缩结果以Vec<u8>返回给 JS，wasm-bindgen会把字节拷回 JS 侧，但 Rust 侧的原始Vec<u8>需要显式free。我忘了调用 free。修法：在 JS 包装类里用FinalizationRegistry注册清理回调：

class WasmCompressor { constructor() { this.inner = wasm.Compressor.new(); // 当 this 被 GC 时，自动释放 WASM 内存 registry.register(this, this.inner.ptr(), this); } compress(imageData) { const result = this.inner.compress(imageData); return new Uint8Array(result.buffer()); } dispose() { this.inner.free(); registry.unregister(this); } } const registry = new FinalizationRegistry((ptr) => { wasm.__wbg_databuffer_free(ptr); });

加了FinalizationRegistry后，即使 JS 侧忘记显式dispose()，GC 也会触发 WASM 内存释放。部署后跑了一天一夜的压测，内存稳定在 120MB 左右。跨语言内存管理的核心就一句话：谁分配谁释放——但如果做不到，至少要有一个兜底的回收机制。

五、总结

WASM 的跨语言互操作本质上是三个世界的对话：

wasm-bindgen 在这中间做了大量的桥接工作，但它不能替代你的安全意识。每当你写#[wasm_bindgen]的时候，问问自己：

1. 数据是传值还是传引用？传引用意味着 JS 侧拿着 WASM 内存的指针——你得保证它活着。
2. 内存谁负责释放？wasm-bindgen 的惯例是：JS 创建的对象 JS 不释放，Rust 创建的对象 Rust 负责释放。
3. 异步边界在哪里？WASM 的 Future 本质上是 JS Promise 的包装——你在 JS 的微任务队列里跑 Rust 的协作调度。的我对"内存管理"一开始是完全懵的。但 WASM 反而让我以可视化的方式理解了这些概念——线性内存就像一整块画布，指针就是画笔的坐标。当你把 Rust 的Vec<u8>和 JS 的Uint8Array想象成同一个画布的不同视图时，悬垂指针这件事就变得直观了。

下一篇预告：用 AI 学编程的最大误区——不是让 AI 代写代码，而是让 AI 教你理解代码。