1. Tauri 不是什么
理解边界会更快建立正确心智模型:
- 它不是'轻量内核包装器(kernel wrapper)',而是直接使用 WRY(WebView 层)与 TAO(窗口与事件循环)去做底层系统交互。
- 它不是 VM 或虚拟化环境,而是一个应用工具箱:你构建的是标准的 OS 应用,只是 UI 用 Web 技术渲染。
2. 总体分层:从 UI 到系统调用的一条链路
你可以把 Tauri 的架构拆成 4 层:前端、桥接、运行时、上游底座。
TAO 和 WRY 是 Tauri 团队维护的关键'上游'组件:TAO 负责跨平台窗口管理,WRY 负责 WebView 渲染与宿主交互抽象。
3. Core Ecosystem:核心 crates 各司其职
下面按'你真的会用到/会踩坑的点'来解释每个 crate 的定位。
3.1 tauri:总装配厂
tauri 是把一切'组装成产品'的主 crate:集成运行时、宏、工具、API,并在编译期读取 tauri.conf.json(以及项目的 Cargo 配置)生成最终应用所需的结构与能力集合;在运行期做脚本注入、API 宿主、更新流程等。
你可以把它理解为: 配置驱动能力裁剪 + 运行时能力宿主 + 跨平台一致抽象
3.2 tauri-runtime:胶水层
tauri-runtime 是 Tauri 与底层 WebView/窗口库之间的'胶水',把不同平台/后端差异收敛成统一 runtime 接口。
3.3 tauri-macros / tauri-codegen / tauri-build:编译期三剑客
这三者经常被一起提到,因为它们都服务于'编译期生成/注入能力'。
tauri-macros:提供上下文、handler、commands 等宏入口(背后依赖 codegen)。tauri-codegen:编译期解析tauri.conf.json并生成配置结构;同时负责资源(assets/icons/tray)嵌入、hash/压缩等。tauri-build:在 build.rs 阶段参与构建,把某些特性'钉'进 Cargo 构建流程。
一句话:你写的少,编译期帮你做的多,这也是 Tauri 二进制能干净利落的原因之一。
3.4 tauri-utils:通用工具箱
配置解析、平台 triple 检测、CSP 注入、资产管理等通用能力,会沉在 tauri-utils 里,供各处复用。
3.5 tauri-runtime-wry:更贴近 WRY 的系统交互扩展
当你需要更直接的系统级能力(例如打印、显示器检测、窗口相关细节等),会落到 runtime-wry 这类与 WRY 紧耦合的能力层里。
4. Tooling:从脚手架到打包发布的'工程化闭环'
Tauri 的工程体验并不是只靠 Rust crate,它配了完整工具链:
- @tauri-apps/api(JS/TS API):给前端提供 cjs/esm/ts 的调用入口,用于在 WebView 中与宿主通信(事件、窗口、webview、fs 等能力会以模块方式组织)。
- CLI(cli.rs + cli.js):核心 CLI 是 Rust 可执行文件,cli.js 通过 napi-rs 做成 npm 平台包,前端生态里安装使用更顺滑。
- Bundler:负责面向目标平台构建与打包(Windows/macOS/Linux 等),把'前端静态产物 + Rust 外壳 + 图标/签名/安装包'串成可分发成品。
- create-tauri-app:脚手架把'前端模板 + Tauri 配置 + 目录结构'一次性搭好。


