Tauri 的进程架构可以用一句话概括：一个轻量的 Rust 主进程 + 每个窗口独立的 WebView 渲染进程。这和 Electron 的“主进程 + 每个窗口一个渲染进程（带完整 Chromium）”在结构上相似，但在实现和资源消耗上有本质区别。
Rust 主进程：真正的“管家”
Tauri 应用启动时，首先运行的是一个由 Rust 编译而成的极小二进制文件。这个主进程负责：
- 管理应用生命周期（启动、退出、系统托盘、菜单）；
- 创建和管理 WebView 窗口（决定窗口大小、位置、装饰等）；
- 处理来自前端的 IPC 请求（调用系统 API、读写文件、执行 Rust 函数）；
- 维护全局状态和安全白名单。
因为是用 Rust 编写，主进程本身就非常精简。它不包含 Node.js 运行时，也没有 V8 引擎的解析开销，内存占用通常只有几 MB。在 Windows 任务管理器里，你会看到它像一个普通的原生程序，低调且高效。
WebView 渲染进程：每个窗口的“画布”
当主进程创建一个新窗口时，Tauri 会启动一个 WebView 实例。这个 WebView 使用的是操作系统内置的浏览器引擎（Windows 上的 WebView2、macOS 上的 WKWebView、Linux 上的 WebKitGTK）。每个 WebView 实例都是一个独立的渲染进程，负责：
- 解析 HTML/CSS/JavaScript；
- 渲染页面；
- 将用户交互事件转发给前端逻辑；
- 通过 IPC 管道与主进程通信（例如调用
window.TAURI.invoke('my_command')）。
与 Electron 不同的是，这里的渲染进程不是 Chromium 的完整副本。WebView2 是 Edge/Chromium 的一个轻量级组件，但由系统共享，多个应用可以共用底层引擎，而且它不需要加载完整的浏览器功能（如扩展、同步、开发者工具等）。因此，即使打开多个窗口，总的内存和 CPU 开销也比 Electron 低得多。
主进程与渲染进程的通信
前端代码运行在沙箱化的 WebView 中，无法直接访问系统资源。任何对文件系统、剪贴板、系统对话框等的操作，都必须通过 Tauri 提供的 invoke API 发送一个命令给主进程。主进程收到命令后，调用相应的 Rust 函数，然后将结果返回。这个过程是异步的，不会阻塞 UI 线程。安全模型默认是“拒绝所有”，开发者需要在配置中显式列出允许的命令清单，防止恶意代码滥用系统接口。
为什么这种架构“轻量又安全”？
- 主进程单例：只有一个 Rust 二进制，内存开销恒定，不会随着窗口增多而线性增长。
- WebView 复用系统资源：没有捆绑浏览器引擎，渲染进程的启动速度极快，内存占用小（每个窗口约 10~30 MB，而 Electron 一个空窗口可能就 50~100 MB）。
- 天然隔离：前端漏洞（如 XSS）无法直接执行系统命令，必须穿透 IPC 白名单，而 Rust 端的校验又增加了第二层保护。
多窗口场景的表现
如果你的应用需要多个独立窗口（比如编辑器的设置窗口、多文档视图），Rust 主进程会为每个窗口创建一个 WebView 实例。这些实例可以配置为共享同一个 IPC 连接，也可以独立通信。由于 WebView 的轻量性，打开 5 个窗口的内存总增长可能只有几十 MB，而 Electron 可能会直接吃满几百 MB。
与 Electron 的直观对比
| 维度 | Electron | Tauri |
|------|----------|-------|
| 主进程 | Node.js 运行时（Chomium + V8） | Rust 原生二进制 |
| 渲染进程 | 完整 Chromium 实例（独立或共享） | 系统 WebView（轻量级） |
| 多窗口内存 | 每个窗口 ≈ 50~100 MB | 每个窗口 ≈ 10~30 MB |
| 热更新 | 需要重启应用重载 JS | 前端支持 HMR（Vite），Rust 需重编译 |
一句话总结：Tauri 的“单主进程 + WebView 渲染进程”模式，把桌面应用的资源消耗拉回了原生级别，同时保留了前端开发的便利性，让多窗口应用也能保持清爽的内存曲线。