Tauri 架构从“WebView + Rust”到完整工具链与生态

1. Tauri 不是什么

理解边界会更快建立正确心智模型：

它不是"轻量内核包装器（kernel wrapper）"，而是直接使用 WRY （WebView 层）与 TAO （窗口与事件循环）去做底层系统交互。 (Tauri)
它不是 VM 或虚拟化环境，而是一个应用工具箱：你构建的是标准的 OS 应用，只是 UI 用 Web 技术渲染。 (GitHub)

你可以把 Tauri 的架构拆成 4 层：前端、桥接、运行时、上游底座。

TAO 和 WRY 是 Tauri 团队维护的关键"上游"组件：TAO 负责跨平台窗口管理，WRY 负责 WebView 渲染与宿主交互抽象。 (Tauri)

下面按"你真的会用到/会踩坑的点"来解释每个 crate 的定位。

tauri 是把一切"组装成产品"的主 crate：集成运行时、宏、工具、API，并在编译期 读取 tauri.conf.json（以及项目的 Cargo 配置）生成最终应用所需的结构与能力集合；在运行期 做脚本注入、API 宿主、更新流程等。 (Tauri)

你可以把它理解为：
配置驱动能力裁剪 + 运行时能力宿主 + 跨平台一致抽象

tauri-runtime 是 Tauri 与底层 WebView/窗口库之间的"胶水"，把不同平台/后端差异收敛成统一 runtime 接口。 (Tauri)

这三者经常被一起提到，因为它们都服务于"编译期生成/注入能力"。

tauri-macros：提供上下文、handler、commands 等宏入口（背后依赖 codegen）。 (Tauri)
tauri-codegen：编译期解析 tauri.conf.json 并生成配置结构；同时负责资源（assets/icons/tray）嵌入、hash/压缩等。 (Tauri)
tauri-build：在 build.rs 阶段参与构建，把某些特性"钉"进 Cargo 构建流程。 (Tauri)

一句话：你写的少，编译期帮你做的多，这也是 Tauri 二进制能干净利落的原因之一。

配置解析、平台 triple 检测、CSP 注入、资产管理等通用能力，会沉在 tauri-utils 里，供各处复用。 (Tauri)

当你需要更直接的系统级能力（例如打印、显示器检测、窗口相关细节等），会落到 runtime-wry 这类与 WRY 紧耦合的能力层里。 (Crates.io)

Tauri 的工程体验并不是只靠 Rust crate，它配了完整工具链：

@tauri-apps/api（JS/TS API） ：给前端提供 cjs/esm/ts 的调用入口，用于在 WebView 中与宿主通信（事件、窗口、webview、fs 等能力会以模块方式组织）。 (npm)
CLI（cli.rs + cli.js） ：核心 CLI 是 Rust 可执行文件，cli.js 通过 napi-rs 做成 npm 平台包，前端生态里安装使用更顺滑。 (GitHub)
Bundler ：负责面向目标平台构建与打包（Windows/macOS/Linux 等），把"前端静态产物 + Rust 外壳 + 图标/签名/安装包"串成可分发成品。 (GitHub)
create-tauri-app ：脚手架把"前端模板 + Tauri 配置 + 目录结构"一次性搭好。 (GitGud.io - Free Git Hosting)

很多人只记得"用系统 WebView"，但忽略了背后两个核心事实：

TAO 就是跨平台窗口与事件循环的统一入口；WRY 是跨平台 WebView 渲染与宿主交互的统一入口。Tauri 在它们之上构建应用框架层。 (Tauri)

插件通常包含三件事：

因此插件既是能力扩展点，也是团队治理点：你可以把敏感能力（文件系统、密钥、数据库等）集中在插件层，并通过配置与 capability 机制做"默认拒绝，按需开放"。（你前面贴的 project structure 里 capabilities/ 就是这种思路的落地。）

如果你要把架构优势转化成"项目可维护性"，我建议抓住三条主线：