Tauri 调用 C++ 动态库：跨语言异常崩溃的防护实践

Tauri 的桌面应用是一套「WebView 前端 + Rust 核心」的双层结构：前端通过 invoke 调用 Rust 侧注册的命令函数，文件、系统、硬件这些脏活都由 Rust 承担。这套模型对纯 Rust 依赖很好用，但工程里更常见的局面是：能力躺在一个现成的 C/C++ 动态库里——硬件厂商只提供 C++ SDK，历史模块闭源，重写不现实——于是 Rust 只能通过 FFI 去调它。

某项目正是这种局面：前端是 Vue 页面，Rust 侧用 libloading 在运行时加载一个 C++ 实现的块存储动态库（下文称 storage.dll），导出加载配置、创建磁盘、创建快照、挂载快照、获取挂载点等一整组 C 风格接口，前端再逐个封装成页面按钮。Demo 很快跑通，然后在真实数据上撞上一记闷棍，进程直接闪退，控制台只剩一行：

这行报错值得每个做跨语言集成的开发者认识。本文复盘它的成因、当时沉淀下来的防护层写法，以及更重要的——这套防护的真实边界。

一、异常为什么跨不过 FFI 边界

Rust 的 panic 与 C++ 的 exception 底层都依赖栈展开（unwind），但这是两套互不相识的语言运行时。当 C++ 侧抛出的异常沿调用栈向上传播、闯入 Rust 的栈帧时，Rust 的异常处理运行时会发现：这不是自己抛出的异常对象，无法解读，也没有接管它的义务。此时标准库不做任何尝试，直接 abort 进程——上面那条 fatal error 就是这么来的。《Rustonomicon》对这条边界的描述更直白：异常穿越 FFI 边界属于未定义行为。

换句话说，这不是一个可以修的 bug，而是 Rust 的明确设计：外来异常，宁死不接。想明白这一点，防护该往哪里使劲就清楚了——异常必须在边界之外被消化掉。

先看集成现场典型的 Rust 代码。libloading 的用法是运行时打开动态库、按符号名取函数指针：

use libloading::{Library, Symbol};
use std::ffi::CString;
use std::os::raw::{c_char, c_uint, c_ulonglong};

#[tauri::command]
fn create_snapshot(
    disk_id: u32,
    parent_snapshot_id: u32,
    size_: u64,
    name: String,
) -> Result<u32, String> {
    unsafe {
        let lib = Library::new("storage.dll").map_err(|e| e.to_string())?;
        let func: Symbol<
            unsafe extern "C" fn(c_uint, c_uint, c_ulonglong, *const c_char) -> c_uint,
        > = lib.get(b"create_snapshot").map_err(|e| e.to_string())?;

        let c_name = CString::new(name).map_err(|e| e.to_string())?;
        Ok(func(disk_id, parent_snapshot_id, size_, c_name.as_ptr()))
    }
}

三个细节最容易出错：函数指针的类型签名必须与 DLL 导出的 C ABI 逐字对齐；String 要经 CString 转成零结尾的 C 字符串，且内容里不允许再含 \0；Windows 上部分接口返回宽字符指针，得用 OsString::from_wide 转回 UTF-8，取长度还得手动扫描到零终止符。个别导出甚至要求传入 C 回调（比如快照导出进度），Rust 侧要用 extern "C" fn 实现一个签名完全一致的函数递过去。

前端一侧，Vue 组件把每个接口包成 async 函数，参数名按 Tauri 的约定做 snake_case 到 camelCase 的映射（cfg_path 对应 cfgPath），invoke 的结果与异常统一在组件里接住、渲染到界面上。这些约定本身不难，难的是出事之后程序还立得住。

站在选型角度也值得先权衡：能用 Rust 生态里的现成 crate 重写，就别碰 FFI；确实绕不开闭源 SDK 时，还要在「进程内 libloading 直连」与「拆一个本地子进程做代理」之间取舍——前者延迟低、代码简单，代价是把 DLL 的稳定性绑死在主进程上；后者多一跳序列化开销，却能换来故障隔离。多数桌面工具类应用交互频率不高，第二种方案的工程收益往往更划算。

二、防护层：让每个命令都能体面地报错

崩溃后的第一轮整改，是给全部十一个 #[tauri::command]（创建磁盘、创建快照、挂载快照、导出快照、获取挂载点等）套上统一的三层防护。

第一层：签名统一返回 Result<T, String>。Tauri 会把 Ok 序列化成前端的 resolve、把 Err 变成 reject，任何错误都能在 Vue 侧被接住并展示，而不是把窗口炸掉。

第二层：unsafe 调用整体包进 std::panic::catch_unwind，panic 被折叠成带函数名的错误串：

use std::panic::catch_unwind;

#[tauri::command]
fn create_snapshot(
    disk_id: u32, parent_snapshot_id: u32, size_: u64, name: String,
) -> Result<u32, String> {
    catch_unwind(|| {
        unsafe {
            let lib = Library::new("storage.dll").map_err(|e| e.to_string())?;
            let func: Symbol<
                unsafe extern "C" fn(c_uint, c_uint, c_ulonglong, *const c_char) -> c_uint,
            > = lib.get(b"create_snapshot").map_err(|e| e.to_string())?;
            let c_name = CString::new(name).map_err(|e| e.to_string())?;
            Ok(func(disk_id, parent_snapshot_id, size_, c_name.as_ptr()))
        }
    })
    .map_err(|_| "Panic occurred in create_snapshot".to_string())?
}

闭包内每个可失败步骤用 ? 向上传播；闭包外先 map_err 把 panic 折叠成错误串，再用 ? 解包。这一行链式写法当时还贡献了一个 expected SEMICOLON 的语法小坑——map_err 与 ? 的组合位置写错，编译器报错虽不友好，倒也帮着把结构理清了。

第三层：main 里挂全局 panic 钩子，任何漏网之鱼至少留下日志、体面退出：

fn main() {
    std::panic::set_hook(Box::new(|info| {
        eprintln!("Caught panic: {:?}", info);
    }));

    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![load_config, create_disk /* ... */])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

这套模式的直接收益是可观测性：每个命令的 panic 都会变成前端能显示的具体错误字符串，而不是无声闪退；错误信息自带函数名，定位一目了然。Vue 侧也值得统一封装：invoke 的 catch 里别只写 console.error，把错误串映射成用户能读懂的文案和重试入口，防护层的价值才能真正落到界面上。示例基于 Tauri v1 的 API 风格，v2 中前端导入路径等有变化，但命令层的模式完全通用。

三、泼冷水：catch_unwind 接不住外来异常

必须诚实地划清这套防护的边界。catch_unwind 的设计目标是捕获 Rust 自己的 panic；而那条 fatal error 恰恰是标准库检测到外来异常后主动 abort 时打印的——abort 就发生在异常展开的路径上，轮不到 catch_unwind 出手。指望这层闭包拦住 C++ 异常，是不现实的。

所以上文防护层的正确定位是「兜底 + 可观测」，不是治愈。真正治本的手段按优先级排：

其一，在 C/C++ 侧加 C 包装层。把所有会抛异常的 C++ 实现包进 try/catch，翻译成错误码或布尔返回值，保证异常永不越过 ABI 边界。这是社区共识的标准做法——如果拿得到 DLL 源码，功夫应该花在这里。

其二，优先选 nothrow 的 C 风格 API。不少 C++ 库同时提供异常版与错误码版两套导出，选型时把「不抛异常」当作硬性条件。

其三，调用前做参数体检。CString::new 遇到含 \0 的字符串会失败，指针有效性、缓冲区大小这类参数在 Rust 侧先校验再传，能消掉一整类「进了 DLL 才炸」的故障。查询类接口常用的「调用方分配缓冲区、返回实际字节数、负值即失败」约定，就属于这类安全契约。

其四，隔离爆炸半径。拿不到 DLL 源码时，把高危 FFI 调用拆进独立子进程，主进程通过管道或本地套接字与之通信——子进程崩了，主界面还能体面报错并把它拉起来。

顺带一个构建配置的坑：如果 Cargo.toml 里把 profile 设成 panic = "abort"，catch_unwind 会彻底失效，闭包里一 panic 进程照样直接终止。防护层上线前，记得确认构建用的是默认的 unwind 策略。

这类集成值得做的场景其实很明确：能力被锁在闭源二进制里、且没有可靠的纯 Rust 替代时，进程内 FFI 加边界防护是成本最低的路；反之，只要存在维护良好的纯 Rust 实现，绕开 C ABI 几乎总是更好的选择。

四、收尾：边界契约决定集成质量

复盘下来，主线其实是一句话：跨语言集成的稳定性，从不取决于某一种语言有多安全，而取决于边界上的契约是否干净。「C ABI、错误码、不抛异常」在边界上约定好，Rust 的类型系统与 Result 化的命令层才能把前端体验稳稳托住；反之，任何一层想用 catch 去兜对方的异常，都是在和标准库的 abort 对赌。

Tauri 加 Vue 的组合让前端同学用熟悉的工具链做出体面的桌面 UI，而 Rust 侧的 FFI 决定了这套 UI 站在哪块地基上。如果你也在做类似集成，建议把「外来异常不可捕获、必须消化在源头」写进团队 FFI 规范的第一行——其余的防护层，才有意义。