Rust Panic 捕获与处理

在 Rust 中，panic 是不可恢复的错误，它会导致当前线程立即展开（unwind）并终止程序（或者在 panic = "abort" 设置下直接 abort）。对于 Tauri 桌面应用来说，一个未处理的 panic 可能意味着窗口突然消失、用户数据丢失，体验极差。因此，如何优雅地捕获和应对 panic，是构建健壮桌面应用必须解决的问题。

Tauri 的 Rust 后端通常运行在独立线程中，前端不会直接感知到后端的 panic。如果 panic 发生在某个 Tauri 命令的执行过程中，该命令会中断，但主进程未必崩溃——这取决于你是否配置了全局 panic hook 和是否使用 catch_unwind。

以下是几个实用且真实的策略：

1. 设置全局 panic hook，记录并友好提示

即使程序崩溃不可避免，也要留下有用的诊断信息。可以在 Rust 入口点设置自定义的 panic hook：

use std::panic;

fn main() {
    panic::set_hook(Box::new(|panic_info| {
        // 记录到文件或发送到远程服务
        if let Some(s) = panic_info.payload().downcast_ref::<&str>() {
            eprintln!("崩溃了：{}", s);
        } else if let Some(s) = panic_info.payload().downcast_ref::<String>() {
            eprintln!("崩溃了：{}", s);
        } else {
            eprintln!("未知原因的崩溃");
        }
        if let Some(location) = panic_info.location() {
            eprintln!("发生在：{}:{}", location.file(), location.line());
        }
    }));

    tauri::Builder::default()
        .run(tauri::generate_context!())
        .expect("启动应用时出错");
}

这样，即使突然崩溃，也能在日志中查到上下文，方便调试。在发布版本中，还可以结合日志库（如 log + env_logger）将 panic 信息写入文件，或弹出系统对话框通知用户（不过这里要注意：panic hook 中应避免再出 panic）。

2. 在命令内部捕获 panic，返回错误给前端

不要让 panic 波及到整个应用。对于可能发生意料之外情况的命令（如解析用户上传的文件、调用不稳定的 C 库等），用 std::panic::catch_unwind 将其包裹起来，把 panic 转换为 Result 返回：

use std::panic;

#[tauri::command]
fn risky_operation(input: String) -> Result<String, String> {
    panic::catch_unwind(|| {
        // 可能 panic 的代码
        if input == "boom" {
            panic!("出错了！");
        }
        input.to_uppercase()
    })
    .map_err(|err| {
        // 将 panic 信息转换为字符串错误
        if let Some(msg) = err.downcast_ref::<&str>() {
            format!("操作失败: {}", msg)
        } else if let Some(msg) = err.downcast_ref::<String>() {
            format!("操作失败: {}", msg)
        } else {
            "操作失败: 未知错误".to_string()
        }
    })
}

前端调用该命令时，会收到一个常规的 Result，可以正常展示错误提示，而不是整个应用崩溃。注意：catch_unwind 只能捕获在展开（unwinding）线程中的 panic。如果 Cargo.toml 中设置了 panic = "abort"，则 catch_unwind 无效，所以发布时建议保留默认的 unwind 策略。

3. 防止状态损坏：结合事务性操作

即使捕获了 panic，也要注意资源泄漏或状态损坏。例如，如果在一个写文件的中途 panic，文件可能处于不完整状态。解决办法是采用原子操作：

写文件时先写临时文件，成功后再重命名；
复杂操作尽量放在 catch_unwind 内部，使用不可变数据，避免共享可变状态；
如果必须修改全局状态（如数据库连接），确保在 panic 发生时重置或回滚。

4. 使用 `tauri::async_runtime` 的安全执行

Tauri 的异步命令通常使用 Tokio 运行时，而 Tokio 默认会捕获异步任务中的 panic，防止它弄塌整个运行时。所以，尽量使用异步命令 + tauri::async_runtime::spawn 来隔离任务：

#[tauri::command]
async fn async_risky_operation() -> Result<String, String> {
    let handle = tauri::async_runtime::spawn(async {
        // 可能 panic 的异步代码
        "safe".to_string()
    });
    handle.await.map_err(|e| format!("任务失败: {}", e))
}

这样，单个异步任务的 panic 只会销毁该任务，不影响其他正在执行的命令。

总结

记录：通过全局 panic hook 留下诊断信息。
捕获：在可能出错的命令内部用 catch_unwind 转成 Result。
隔离：优先使用异步任务或独立线程执行风险操作。
防护：关键数据操作使用事务性模式，避免半完成状态。

做好这些，你的 Tauri 应用就能在遇到意外时优雅降级，而不是默默消失。用户看到的将是“操作失败，请重试”，而不是一次崩溃。

1. 设置全局 panic hook，记录并友好提示

2. 在命令内部捕获 panic，返回错误给前端

3. 防止状态损坏：结合事务性操作

4. 使用 tauri::async_runtime 的安全执行

总结

4. 使用 `tauri::async_runtime` 的安全执行