Tauri 的进程模型可以概括为“一主多渲染”。核心主进程由 Rust 编写，负责所有系统级交互；每个应用窗口则运行在独立的系统 WebView 渲染进程中，专用于 UI 呈现。这种结构在确保前后端彻底隔离的前提下，避免了传统浏览器内核带来的繁重开销。
一、主进程（Rust Core）
应用启动时，最先运行的是一个极小的 Rust 二进制文件。它的职责非常集中：
- 创建并管理所有窗口、系统托盘、菜单；
- 注册并响应来自前端的 IPC 命令；
- 调用文件系统、剪贴板、通知、全局快捷键等原生 API；
- 控制应用的生命周期（如退出请求、休眠恢复）。
主进程不包含任何 UI 代码，它只通过高效的序列化通道与渲染进程交换数据。得益于 Rust 的零成本抽象和精细的内存管理，主进程自始至终的内存占用通常控制在几 MB 以内。
二、渲染进程（WebView）
每个窗口的内容都由操作系统原生的 WebView 引擎独立渲染。根据当前平台的不同，具体实现为：
- Windows：基于 Edge 的 WebView2，每个 WebView2 实例默认启动独立的渲染进程；
- macOS：采用 WKWebView，系统为每个 WebView 分配专用进程来保证隔离；
- Linux：使用 WebKitGTK，同样遵循一个窗口一个渲染进程的原则。
这些渲染进程只负责解析 HTML/CSS/JavaScript，无权直接访问磁盘、网络或任何系统资源。任何越界的操作都必须通过预定义的 IPC 向主进程申请，这从根本上切断了恶意脚本的攻击路径。
三、进程间通信（IPC）
主进程与渲染进程之间通过 Tauri 内置的 IPC 管道通信，底层依赖 WebView 的 postMessage 机制。开发者只需在 Rust 中定义命令并用 #[tauri::command] 导出，前端就能通过 invoke('命令名', {参数}) 无缝调用。所有参数和返回值都会经过严格的类型校验与 JSON 序列化，避免注入攻击。
四、进程模型的实际影响
- 安全隔离
前端即使被 XSS 或恶意依赖污染，也无法绕过白名单调用未授权的系统 API。IPC 通道天然起到防火墙的作用。
- 稳定性
单个窗口的渲染进程崩溃（例如页面内存溢出），不会拖垮主进程或其他窗口。用户在关闭出错窗口后，应用其余部分仍可继续正常工作。
- 资源占用
由于没有 Chromium 的 GPU 进程、网络进程、插件进程等额外组件，每个渲染进程只包含页面所需的基本资源。一个空白窗口应用在 Windows 上通常仅产生 2 个进程（主进程 + 一个渲染进程），总内存常常低于 20 MB。
- 可选的进程共享
如果多个窗口需要频繁共享大量状态（类似浏览器标签页），可以通过 WebView 的启动参数或环境变量适当调整进程模型，但出于隔离性考虑，Tauri 默认采用 一窗口一进程 的安全策略。
五、与 Electron 的直观对比
Electron 的进程模型包括主进程（Node.js）、每个窗口的渲染进程（Chromium），以及可能存在的 GPU、网络、扩展等辅助进程。启动一个 Hello World 应用就常伴生 4–5 个进程。而 Tauri 将渲染工作完全交由系统原生 WebView，主进程仅用极小的 Rust 内核，进程数量与内存开销骤减至后者的几分之一。
这种简单而坚固的进程设计，让开发者可以像写普通 Web 应用一样构建 UI，同时享受原生程序的安全性和轻量性，无需为进程管理分配额外精力。