Tauri 前端和 Rust 后端如何进行 IPC 通信？

Tauri 的 IPC 通信，本质上是在 WebView 前端和 Rust 后端之间建立一条受控通道。前端不能直接调用系统 API，而是通过 invoke 请求 Rust 命令；Rust 也可以通过事件把状态推回前端。这个模型比“前端拿到完整 Node 能力”更收敛，但也要求你认真设计命令边界、数据结构和错误处理。

前端调用 Rust 命令

Tauri 2 中常用 @tauri-apps/api/core 的 invoke：

ts
import { invoke } from '@tauri-apps/api/core';

const result = await invoke<string>('greet', { name: 'World' });
console.log(result);

Rust 端用 #[tauri::command] 标记函数，并注册到 handler：

rust
#[tauri::command]
fn greet(name: String) -> String {
    format!("Hello, {name}!")
}

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

参数通过 JSON 序列化传递，所以前端对象字段名要和 Rust 参数匹配。简单类型可以直接传，复杂对象建议定义结构体，避免一堆散参数让接口变脆。

复杂数据怎么传

Rust 结构体需要实现 Serialize 和 Deserialize：

rust
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize)]
struct SaveNoteInput {
    title: String,
    body: String,
}

#[derive(Debug, Serialize)]
struct SaveNoteOutput {
    id: String,
    saved: bool,
}

#[tauri::command]
fn save_note(input: SaveNoteInput) -> Result<SaveNoteOutput, String> {
    if input.title.trim().is_empty() {
        return Err("title is required".into());
    }
    Ok(SaveNoteOutput { id: "note-1".into(), saved: true })
}

前端调用时保持同样的数据形状：

ts
await invoke('save_note', {
  input: { title: 'todo', body: 'ship desktop app' }
});

Rust 主动通知前端

短请求用 invoke 足够，长任务进度更适合事件。比如 Rust 处理文件时持续推送进度：

rust
use tauri::{Emitter, Window};

#[tauri::command]
async fn import_files(window: Window) -> Result<(), String> {
    for progress in [10, 40, 70, 100] {
        window.emit("import-progress", progress).map_err(|e| e.to_string())?;
    }
    Ok(())
}

前端监听后记得取消订阅：

ts
import { listen } from '@tauri-apps/api/event';

const unlisten = await listen<number>('import-progress', (event) => {
  console.log(event.payload);
});

// 组件卸载时调用
unlisten();

错误处理不要只返回字符串

示例里常用 Result<T, String>，但生产项目可以定义更稳定的错误格式。这样前端可以根据错误码做提示，而不是解析中文错误消息。取舍是 Rust 代码稍微多一点，但后续国际化、埋点和自动化测试都会更稳。

异步命令和状态管理

耗时任务应该写成 async command，并避免阻塞主线程。Rust 侧可以把 CPU 密集任务放到专门线程，I/O 任务用 async 处理，前端则用 loading、取消按钮和事件进度展示状态。一个常见模式是 invoke 启动任务，返回任务 ID，再通过事件接收进度：

rust
#[tauri::command]
async fn start_export(window: tauri::Window) -> Result<String, String> {
    let task_id = "export-1".to_string();
    window.emit("export:progress", 1).map_err(|e| e.to_string())?;
    Ok(task_id)
}

前端不要把 IPC 结果直接散落到多个组件里。React 可以放到 hook，Vue 可以放到 composable，Svelte 可以放到 store。这样错误提示、重试、取消订阅都能集中处理。代价是抽象层略多，但当命令数量超过十几个时，会明显减少“这个事件到底谁在听”的混乱。

前端类型也要跟着维护

为了避免命令参数改了前端还不知道，团队可以给 IPC 单独维护类型声明：

ts
type SaveNoteInput = { title: string; body: string };
type SaveNoteOutput = { id: string; saved: boolean };

这不能替代 Rust 校验，但能减少调用方传错字段。更进一步可以从 Rust 结构生成 TypeScript 类型，不过会增加构建链路复杂度。小项目手写类型足够，大项目再考虑生成方案。关键是把 IPC 当成接口，而不是随手调用的内部函数。

命令命名和版本兼容

IPC 命令名一旦被前端使用，就像内部 API 一样需要稳定。建议用动词加业务名，例如 notes_save、settings_load、export_start，不要用 handle、do_work 这种含糊名字。参数结构升级时尽量向后兼容，新增字段用 Option 或默认值处理。桌面应用存在旧版本用户，自动更新也可能失败，所以不能假设所有前端和 Rust 永远同步发布。

追问

invoke 和事件应该怎么选？

一次性请求用 invoke，比如读取配置、保存表单、获取应用版本。持续状态用事件，比如下载进度、文件扫描、后台任务日志。边界是：如果前端需要等待一个明确结果，invoke 更简单；如果 Rust 需要多次推送，事件更自然。常见坑是用循环 invoke 轮询进度，既浪费资源，也让取消逻辑变复杂。

IPC 传大文件合适吗？

不合适。IPC 适合传结构化数据，不适合把几十 MB 的文件内容塞进 JSON。更好的做法是前端选择文件路径，Rust 侧读取和处理，只把进度、摘要或结果路径传回前端。取舍在于前端不能随意拿到所有原始内容，但性能和内存会稳定很多。大文件直接传 IPC，开发机可能没问题，用户机器上就可能卡死。

参数校验应该放前端还是 Rust？

两边都要做，但 Rust 侧必须做。前端校验是为了体验，Rust 校验是为了安全和数据一致性。边界很清楚：任何来自 WebView 的参数都不能默认可信，即使这个页面是你自己写的。踩坑点是把前端 TypeScript 类型当成运行时保证，实际上用户或注入脚本仍可能传入异常数据。

多窗口通信怎么处理？

如果只是 Rust 通知某个窗口，用对应 Window emit 即可；如果要广播，可以通过 app handle 发事件。多窗口应用要注意事件名隔离，避免设置窗口收到编辑窗口的业务事件。取舍是全局事件方便，但长期会变成“谁都能听、谁都能发”的隐式依赖。建议事件名带业务前缀，例如 settings:changed、import:progress。

IPC 会不会成为性能瓶颈？

普通表单和配置读写不会，瓶颈通常来自高频调用和大 payload。比如拖动滑块每 10ms 调一次 Rust 命令，就会让 UI 和后端都很难受。可以用 debounce、批量提交或把计算放到前端完成。IPC 是边界，不是函数调用的廉价替代品，设计时要把跨边界次数当作成本。