为什么选择 Tauri

选框架最忌讳「谁火选谁」或「谁小选谁」。Tauri 和 Electron 都是成熟方案，差别来自底层设计理念。先把理念讲清，再谈选型才靠谱。

本质差异：浏览器是「借」还是「带」

Electron 的做法是：把一整个 Chromium 浏览器 和 Node.js 运行时 一起打进安装包。好处是环境完全自包含，你在什么机器上跑，表现都一致；代价是每个应用都背着一整套浏览器。

Tauri 的做法是：浏览器内核不打包，直接用系统自带的 WebView（Windows 的 WebView2、macOS 的 WKWebView、Linux 的 WebKitGTK）。后端用 Rust 编译成原生二进制，不带运行时。

这一条「借还是带」的区别，几乎决定了后面所有对比项。

安装体积与内存：Tauri 为何更小

因为不打包浏览器，Tauri 的安装包天生就小。社区里常被引用的一个直观对比是：一个 Electron 的「Hello World」打出来往往 150MB 以上，而同等最简的 Tauri 应用可以压到 几 MB，官方给出的最小体积参考甚至低于 600KB。

内存也是同理。空跑的 Electron 应用常占用 百 MB 量级 的内存（其中很大一部分是 Chromium 本身），Tauri 因为只加载系统 WebView 加一个轻量 Rust 核心，空载内存通常明显更低。

体积和内存小，对工具类软件、托盘常驻程序尤其重要——用户不愿意为一个「就显示个图标」的小工具腾出上百 MB。

安全模型：最小权限 vs 全权 Node

这是理念上更关键的分歧点。

Electron 里前端能直接调 Node.js，等于默认拥有近乎完整的系统权限。方便是真方便，但一旦前端被注入恶意脚本，攻击面就很大。

Tauri 反过来，遵循最小权限原则：前端不能直接碰系统，想读文件、发请求、弹通知，都必须由后端 Rust 显式提供「命令」，并且还要在能力（capability）配置里明确授权才放行。没声明的能力，默认一律拒绝。这套机制我们在后面的安全和权限章节会展开。

官方还强调，Tauri 基于 Rust 编写，天生带有内存安全、线程安全的保障，并且对每个大版本做第三方安全审计。这给应用打了一层「底层安全地基」。

灵活性：前端任选、后端可扩展

Tauri 对前端极其宽容：几乎任何能编译成 HTML/CSS/JS 的框架都能用，Vue、React、Svelte、Solid 都不挑。前后端通过 invoke 函数通信，插件体系还提供了 Swift、Kotlin 等移动端语言的绑定。

底层的两个库 TAO（管窗口创建）和 WRY（管 WebView 渲染）都由 Tauri 团队维护。当你需要超出 Tauri 封装的更深系统集成的，也可以直接调用它们。

什么时候 Tauri 更合适

• 新项目，没有 Electron 历史包袱。
• 对安装体积、内存敏感，比如小工具、托盘程序、内部效率软件。
• 需要同时覆盖桌面和移动端（Tauri 2.x 把 Android / iOS 当一等公民）。
• 对安全性要求高，愿意用「显式授权」换可控的攻击面。
• 团队有 Rust 基础，或愿意为后端学一点 Rust（日常写命令其实不多）。

什么时候 Electron 更合适（客观视角）

讲 Tauri 优点时，不该把 Electron 说成「该被淘汰」。它有自己的主场：

• 已有成熟 Electron 项目，迁移成本高、收益不明确，没必要为换而换。
• 重度依赖 Node.js 原生模块，比如 node-pty、sharp、音视频处理等，Electron 的生态直接可用。
• 需要非常老的系统支持，例如 Windows 7，Electron 的覆盖更稳。
• 团队完全没有 Rust 经验且工期紧，Tauri 的学习曲线主要在 Rust 侧（虽然 #[command] 宏已封装了大量复杂度）。
• 依赖 Chromium 专属能力，比如某些只能在完整 Chrome 内核上跑的扩展或特性。

小结

Tauri 的核心吸引力来自「不打包浏览器 + Rust 后端 + 最小权限」。它换来的是小体积、低内存和更可控的安全模型；代价是你要接受系统 WebView 的跨平台差异，以及一点点 Rust 学习成本。Electron 则用「自包含环境」换了稳定和生态成熟。两者没有高下，只有适配。

下一章我们钻进 Tauri 内部，看看它的进程模型和 IPC 到底长什么样。