111.2k Star 的 Tauri：不捆绑 Chromium 的跨平台应用框架

用 Web 技术开发桌面应用，Electron 是绕不开的方案。VS Code、Slack 和 Discord 都证明了它的成熟度，但每个应用都携带 Chromium 与 Node.js 运行时，也会带来更大的安装包和更高的基础资源占用。

Tauri 走了另一条路：前端继续使用 HTML、CSS 和 JavaScript，渲染则复用操作系统提供的 WebView，应用逻辑和原生能力由 Rust 承担。它不是”更小的 Electron”这么简单，而是一套在包体积、兼容性、安全边界和开发成本之间重新取舍的框架。

Tauri 是什么

Tauri 的目标是创建小、快、安全的跨平台应用。开发者可以继续使用 React、Vue、Svelte、Solid 或原生 Web 技术编写界面，通过 Tauri 的命令与插件调用文件系统、窗口、通知等原生能力；需要更复杂的业务逻辑时，再在 Rust 侧实现。

Tauri 2 已覆盖 Windows、macOS、Linux、iOS 和 Android。项目采用 MIT 或 Apache-2.0 双许可证，属于 Commons Conservancy 旗下项目。桌面与移动端共享大量代码，但构建、签名和平台能力仍要分别处理，不能把它理解成”写一次就无需适配”。

核心架构：系统 WebView + Rust

Tauri 的桌面架构中，WRY 负责统一各平台 WebView 接口：Windows 使用 WebView2，macOS 使用 WKWebView，Linux 使用 WebKitGTK。TAO 则负责创建窗口、处理事件和管理窗口生命周期。

因为不随应用捆绑完整浏览器，简单 Tauri 应用的安装包可以做得很小。常见项目的实际体积仍会受到前端资源、Rust 依赖、插件、WebView2 分发方式和安装包格式影响，因此”600KB”更适合作为极简示例的量级，而不是所有应用的承诺。

这套架构也带来一个明确代价：不同平台使用的 WebView 引擎和版本并不完全一致。Electron 通过内置 Chromium 获得更统一的渲染环境，Tauri 则用更小的包体积换取了额外的跨平台测试成本。

六个值得关注的特性

1. 复用系统 WebView

Windows 使用 WebView2，macOS 和 iOS 使用 WKWebView，Linux 使用 WebKitGTK，Android 使用系统 WebView。应用不必重复携带 Chromium，但前端代码要面对不同引擎的兼容性差异。

2. Rust 后端，前端框架不限

Tauri 对前端框架没有强绑定，只要最终能产出 HTML、CSS 和 JavaScript 静态资源即可。Rust 侧负责编译为原生二进制，并通过命令、事件和插件向前端暴露能力。简单应用不必一开始就深入 Rust，但涉及原生集成、并发或复杂状态时，Rust 能力会成为实际门槛。

3. 桌面与移动端覆盖

桌面端支持 Windows、macOS 和 Linux；Tauri 2 进一步支持 iOS 和 Android。常见桌面构建产物包括 .app、.dmg、.deb、.rpm、.AppImage、NSIS .exe 和 WiX .msi，移动端则遵循各自商店与签名流程。

4. Capability 权限模型

Tauri 通过 Capability 和 ACL 配置限制不同窗口或 WebView 能调用哪些命令与插件权限。权限需要显式配置，减少前端内容直接触达系统能力的范围。removeUnusedCommands 还可以在满足版本条件时剔除未授权、未使用的命令，进一步缩小二进制和攻击面。

这套模型能提供更细的边界，但安全仍取决于权限配置、前端内容来源、更新链路和插件质量。使用 Tauri 并不会自动消除 XSS、供应链或密钥泄露风险。

5. 更新与系统集成

官方插件覆盖自动更新、文件系统、对话框、HTTP、剪贴板、全局快捷键、通知等常用能力。系统托盘、菜单和窗口管理也有相应 API。与 Electron 相比，插件总量和第三方成熟度仍有差距，选型前最好先确认关键能力是否已有稳定实现。

6. 完整的构建与发布工具链

Tauri CLI 可以生成项目、构建原生包，并与官方 GitHub Action 配合完成多平台发布。真正上线时，Windows 代码签名、macOS 签名与公证、移动端证书，以及 Linux 发行格式仍要分别配置。

一条命令开始

最直接的脚手架命令是：

npm create tauri-app@latest

也可以使用 Yarn、pnpm、Bun、Deno 或 Cargo。脚手架会让你选择前端框架和语言，再生成完整项目骨架。

开发时，前端通常配合 Vite 等工具热更新，Rust 代码变更则需要重新编译。构建阶段会把前端产物打进应用，并生成目标平台对应的安装包。

跨平台发布要特别注意构建环境。最稳妥的方式仍是在对应平台或 CI Runner 上构建和签名。Tauri 支持在 Linux、macOS 上交叉构建 Windows NSIS 安装包，但官方也明确提示存在限制；WiX .msi 仍需在 Windows 上生成。用 GitHub Actions 的矩阵任务为不同平台分别构建，通常更省心。

和 Electron 的差别

两者最根本的差异是运行时策略。Electron 随应用分发固定版本的 Chromium 和 Node.js，安装包更大，但渲染行为更一致，生态和调试工具也更成熟。Tauri 复用系统 WebView，基础体积通常更小，却需要承担更多跨平台兼容性测试。

资源占用和启动速度不能只由框架决定。页面复杂度、后台任务、插件和数据量都会影响结果；在同等功能、同等测试条件下比较自己的应用，比引用”快几倍”或”省多少内存”的通用数字更可靠。

安全模型上，Tauri 用 Capability ACL 限制前端可以调用的原生接口。现代 Electron 的 nodeIntegration 默认同样是关闭的，也提供 Context Isolation、Sandbox 等机制。Tauri 的优势是权限声明更细、Rust 后端默认暴露面更小，但两者都需要正确配置，不能简单归纳为”一方安全、一方不安全”。

移动端是 Tauri 2 的明显扩展，而 Electron 主要面向桌面。不过，Tauri 在移动端的生态和成熟度仍在追赶桌面端，涉及推送、后台任务、支付或复杂原生 SDK 时，需要提前做原型验证。

适合什么项目

Tauri 比较适合以下场景：

• 团队已有成熟 Web 前端，希望快速延伸到桌面端。
• 应用对安装包体积、空闲资源占用和启动体验比较敏感。
• 需要用 Rust 实现本地能力，并希望细粒度控制前端权限。
• 希望在桌面代码基础上继续探索 iOS 和 Android。

门槛也很清楚。Rust 会增加学习和编译成本；系统 WebView 会带来平台差异；部分 Electron 插件没有一一对应的 Tauri 实现；签名、自动更新和移动端原生集成仍需要平台知识。

如果项目重度依赖 Electron 生态、需要完全一致的 Chromium 行为，迁移未必划算。反过来，如果应用功能相对聚焦，又确实受包体积和资源占用困扰，Tauri 很值得做一版真实原型再比较。

Tauri 的价值不在于用一个醒目的体积数字”击败” Electron，而在于提供了另一种运行时选择：不捆绑浏览器，把原生能力收进 Rust 与权限系统中。是否采用，最终应由关键插件、跨平台测试结果、团队 Rust 能力和发布成本共同决定。

项目地址：github.com/tauri-apps/tauri
官网：tauri.app
快速开始：npm create tauri-app@latest