1.1 什么是Tauri：壳与芯的装配观
1.1 什么是 Tauri：壳与芯的装配观
本节是全书的起点：先给 Tauri 一个准确的定义，再亲手创建一个最小项目，用真实目录和真实命令把"壳与芯"从比喻落到文件系统上。读完本节，第 2 章拆架构时你脑中会有具体文件可对照，不会停在抽象名词上。
先把定义钉住
Tauri 是一个用 Rust 编写的应用框架，它让你用前端技术（HTML、CSS、JavaScript，或 React、Vue、Svelte 任何主流框架）构建图形界面，用 Rust 编写后端逻辑，最终把两者装配成一个原生桌面应用。它有两个事实常被忽略，而这两个事实恰恰决定了你之后写代码的所有姿势：
第一，它不自带浏览器内核。 Electron 每个应用都打包一整台 Chromium；Tauri 不打包，而是在 Windows 上加载系统的 WebView2，在 macOS 上加载 WKWebView，在 Linux 上加载 WebKitGTK。界面渲染这件事，交给操作系统里本来就有的组件。
第二，后端不是 Node，而是 Rust。 前端 JS 没法直接碰文件系统、窗口、进程这些系统能力——这些能力住在 Rust 侧。前端要做什么事，通过 invoke 机制调用你在 Rust 里写的命令函数，Tauri 负责跨语言的参数序列化与结果回传。
把这两点合起来，就有了本册反复使用的模型：系统 WebView 做壳，Rust 二进制做芯，命令与事件是壳芯之间的传送带。壳负责"看得见的部分"，芯负责"摸得着的部分"。
图 1-1：主流 GUI 方案的光谱位置
动手：五分钟摸到壳与芯
装好环境之前先看全流程（环境的完整安装留在 3.1，这里假设依赖齐备）。用官方脚手架创建项目：
npm create tauri-app@latest # 交互式提示依次回答： # Project name ... travel-notes # Identifier ... com.example.travel-notes # Frontend language ... TypeScript / JavaScript # UI template ... Vanilla（本书示例混用 Vanilla 与 Vue） # UI flavor ... TypeScript
创建完成后目录长这样（省略了锁文件与杂项）：
travel-notes/ ├── index.html # 前端入口 ├── src/ # 前端源码（选了框架则是框架工程） ├── package.json # 前端依赖与脚本 └── src-tauri/ # Rust 芯所在的独立工程 ├── Cargo.toml # Rust 依赖清单 ├── tauri.conf.json # 装配说明书：窗口、安全、打包全在这 ├── capabilities/ # 权限清单：声明前端能用哪些能力 ├── icons/ # 各平台应用图标 └── src/ ├── main.rs # 芯的入口 └── lib.rs # 命令与初始化逻辑
目录结构本身就是装配观的体现：src 是装进壳里的面板，src-tauri 是芯工厂。启动开发模式：
cd travel-notes npm install npm run tauri dev
首次运行会编译整个 Rust 依赖树，慢是正常的；之后增量编译只需数秒。跑起来后会弹出一个原生窗口——这就是壳在工作。窗口里右键有"检查元素"，那是 WebView 的开发者工具，调试前端与调试网页没有区别。
芯长什么样？打开 src-tauri 侧的 lib.rs，脚手架生成的代码剥掉注释后核心是这一段：
#[tauri::command] fn greet(name: &str) -> String { format!("Hello, {}! 你来自 Rust 芯。", name) } #[cfg_attr(mobile, tauri::mobile_entry_point)] pub fn run() { tauri::Builder::default() .invoke_handler(tauri::generate_handler![greet]) .run(tauri::generate_context!()) .expect("error while running tauri application"); }
五个值得读出声的细节：#[tauri::command] 把普通函数登记为前端可调用的命令；generate_handler! 宏把命令挂到调用路由上；generate_context! 宏在编译期读取 tauri.conf.json 与图标，把配置烧进二进制；mobile_entry_point 说明同一份芯代码也服务于移动端；而 greet 就是一个普通 Rust 函数——Tauri 的命令系统没有引入任何魔法类型，这是第 5 章能轻松写命令的原因。
前端侧调用它只需要几行：
// 前端：调用 Rust 侧的 greet 命令 import { invoke } from '@tauri-apps/api/core'; const msg = await invoke('greet', { name: '装配工' }); console.log(msg); // Hello, 装配工! 你来自 Rust 芯。
这一来一回就是壳与芯的完整握手。参数 { name: ... } 被序列化成 JSON 跨过进程边界，Rust 侧反序列化进 &str，返回值再序列化回前端。第 2 章会把这条传送带拆开看每一站，第 5 章教你批量造这样的命令。
历史的坐标：它不是横空出世
Tauri 项目 2019 年启动，2022 年发布 1.0，2024 年秋发布 2.0 稳定版并带来两件大事：权限体系从 1.0 的 allowlist 整体重做成 Capabilities（能力清单，第 6 章详述），以及移动端支持落地——同一套工程可以产出 iOS 与 Android 应用。2026 年回看，2.x 已是官方主推且社区插件的默认目标版本；网上还能搜到大量 1.0 时代的教程，其 allowlist 写法在 2.x 里已失效，读旧资料时先核对版本，能省下大把排错时间。
本节要点回顾
- Tauri 的定义：Rust 编写的应用框架，前端做界面、Rust 做后端，装配成原生桌面应用；
- 壳：系统 WebView（Windows 用 WebView2、macOS 用 WKWebView、Linux 用 WebKitGTK），不随应用分发；
- 芯：你的 Rust 代码编译出的二进制，独占全部系统能力；
- 传送带：前端 invoke 命令、双向事件，跨进程通信由 Tauri 代管；
- 目录语义：前端工程与 src-tauri 工程并列，前者是面板后者是芯，tauri.conf.json 是装配说明书；
- 命令即普通函数：
#[tauri::command]不引入魔法，参数与返回值走 JSON 序列化； - 版本意识：本册基于 Tauri 2，1.0 的 allowlist 等旧机制不再适用。
下一节深挖这套架构背后的三条设计承诺——你会看到"轻量"与"安全"不是宣传词，而是能在代码里逐条指认的取舍。