跳到主要内容

Tauri

Tauri 适合放在“想做桌面端，但又不太想把一整套浏览器引擎都打进安装包”的那条线上看。它和 Electron 一样可以用 Web 技术写界面，但底层路线完全不同。

如果 Electron 的思路是“自己把 Chromium 带进去”，Tauri 的思路更像是“尽量借用系统已有的 WebView，再把系统能力和安全边界收紧”。

一句话先讲清楚​

Tauri 是一个用 Web 前端加 Rust 后端来构建桌面端和移动端应用的框架。

官方 What is Tauri? 页面给出的说法很直接：

  • 可以接入任何能编译成 HTML、JavaScript、CSS 的前端框架
  • 后端逻辑可以用 Rust，也能扩展到 Swift、Kotlin 等语言
  • 面向主流桌面和移动平台

这几个点基本决定了它的气质：

  • 前端层很自由
  • 后端能力很强
  • 安全边界抓得比较紧
  • 体积通常比 Electron 小很多

适合什么场景​

  • 希望继续用现有前端技术栈做桌面端
  • 对安装包体积和资源占用比较敏感
  • 需要系统能力，但希望权限和暴露面更可控
  • 团队愿意接受一点 Rust 学习成本

不太适合什么场景​

  • 团队完全不想碰 Rust
  • 更重视桌面生态成熟度和历史资料积累
  • 项目需要非常多的现成桌面端生态方案，且希望“开箱就有”

Tauri 的核心结构​

可以先把它理解成三层：

  • 前端层：React、Vue、Svelte、Solid 等都可以
  • Tauri 核心层：窗口、事件、命令、插件、权限体系
  • Rust 系统层：真正的本地逻辑和系统调用

官方文档里对这点说得很明确：几乎任何前端框架都能和 Tauri 兼容，前端与 Rust 之间的绑定主要通过 invoke 来完成。

Tauri 为什么会显得更轻​

因为它默认不打包 Chromium。

官方 What is Tauri? 页面把这一点归纳成“smaller app size”。它直接利用用户系统已有的 WebView，所以一个最小 Tauri 应用可以非常小。

这也是 Tauri 最吸引人的地方之一：

  • 包体积更小
  • 资源占用通常更克制
  • 桌面端交付时不需要再把整套 Chromium 搬进去

但这个优势也伴随着现实约束：系统 WebView 的具体表现，会受到目标平台环境影响。

Tauri 项目通常长什么样​

最常见的结构通常是：

src/
  components/
  pages/
  lib/
src-tauri/
  src/
    lib.rs
    main.rs
  tauri.conf.json
  capabilities/

可以把它理解成：

  • src/：前端项目
  • src-tauri/：Tauri 与 Rust 后端
  • capabilities/：权限和能力声明

前端和 Rust 怎么通信​

这是 Tauri 的主线之一。

官方开发文档里给出的核心机制是 command 系统。前端通过 invoke() 调用 Rust 里的命令函数，命令可以接收参数、返回数据，也可以返回错误。

#[tauri::command]
fn greet(name: String) -> String {
  format!("Hello, {}!", name)
}
import { invoke } from '@tauri-apps/api/core'

const message = await invoke<string>('greet', { name: 'Torli' })
console.log(message)

如果前端团队以前做过“页面层调本地能力”的事情，会很快意识到：这其实就是 Tauri 版本的前后端边界。

Capabilities 为什么值得单独讲​

Tauri 2 里很关键的一点，就是权限和能力控制明显比很多桌面框架更细。

官方 Capabilities 文档的核心意思是：

  • capability 用来决定哪些 window / webview 拥有哪些权限
  • capability 文件通常放在 src-tauri/capabilities 目录下
  • 可以按窗口、平台、插件权限去拆

这意味着 Tauri 不只是“能调系统 API”，而是更强调“哪些地方能调、哪些地方不能调”。

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "main-capability",
  "windows": ["main"],
  "permissions": [
    "core:window:default",
    "core:event:default",
    "dialog:default"
  ]
}

这类配置一开始会显得比 Electron 麻烦一点，但项目一旦变大，这种约束往往不是负担，反而是保护。

Tauri 的优势到底在哪​

1. 前端栈自由​

官方文档明确写了，几乎任何前端框架都能接进来。对现有 Web 团队来说，这点非常重要。

  • React 可以接
  • Vue 可以接
  • Svelte 可以接
  • Vite 这类构建链也很好配

2. 体积和资源占用通常更友好​

这点就是 Tauri 最常被拿来和 Electron 比较的地方。

对下载体积、安装分发、内存占用比较敏感的项目，Tauri 很有吸引力。

3. 权限体系更清楚​

Tauri 2 的 capability / permission 体系让“系统能力暴露多少”这件事不再只靠约定，而是有配置层约束。

4. Rust 侧能力很强​

一旦项目需要：

  • 本地文件处理
  • 高性能计算
  • 更稳定的本地服务
  • 更细的系统交互

Rust 这一层会非常有价值。

Tauri 的代价也要讲清楚​

1. 团队需要接受 Rust​

哪怕前端层完全熟悉，只要开始写 command、插件、系统交互，Rust 就会进场。

这不是缺点，但确实是门槛。

2. 生态成熟度不如 Electron​

Tauri 已经很成熟了，但如果和 Electron 这种跑了很多年的桌面生态相比，现成资料、历史案例、第三方工具链，还是会少一些。

3. 调试链路会更分层​

项目通常会同时碰到：

  • 前端构建问题
  • Tauri 配置问题
  • Rust 编译问题
  • 平台打包和签名问题

这意味着问题定位会跨层，不只是前端单层的心智模型。

Tauri 项目里最值得先建立的边界​

1. 前端只负责界面和交互​

不要一开始就把大量系统逻辑堆到前端层。前端更适合做：

  • 页面结构
  • 表单交互
  • 状态展示
  • 命令调用入口

2. Rust 负责本地能力和重逻辑​

适合放到 Rust 的通常是：

  • 本地文件系统读写
  • 复杂数据处理
  • 长时间后台任务
  • 系统级集成

3. 权限声明尽早收紧​

capabilities 不要拖到最后再补。越晚补，越容易把权限开得过大。

Tauri 和 Electron 怎么选​

这是最常见的问题。

一个很直接的判断是：

  • 想要更成熟的桌面生态、资料更多、团队更容易马上上手：先看 Electron
  • 更在意体积、资源占用、安全边界和 Rust 后端能力：先看 Tauri

再具体一点：

优先选 Tauri 的情况​

  • 体积和资源占用很重要
  • 团队不排斥 Rust
  • 希望系统能力有更细的权限控制
  • 项目本身偏工具型、客户端型、本地能力明确

优先选 Electron 的情况​

  • 团队几乎纯前端，不准备进入 Rust
  • 需要成熟资料和历史经验兜底
  • 更重视快速交付一套功能完整的桌面应用

我的看法​

Tauri 最有意思的地方，不只是“小”，而是它把桌面端这件事重新做了一次取舍。

它没有沿着“把浏览器全带上”的方向继续堆，而是把体积、安全和系统边界这些问题拉回了框架中心。对于很多现代桌面工具来说，这个取舍是成立的。

如果团队能接受前端加 Rust 这条路，Tauri 很值得认真看。尤其是在 Electron 已经显得有点重的时候，Tauri 往往会变成非常现实的候选项。