1. 厘清边界
理解 Tauri 的边界，能更快建立正确的技术心智模型。
它不是轻量内核包装器，而是直接使用 WRY（WebView 层）与 TAO（窗口与事件循环）去做底层系统交互。它也不是 VM 或虚拟化环境，而是一个应用工具箱：你构建的是标准的 OS 应用，只是 UI 用 Web 技术渲染。
2. 总体分层：从 UI 到系统调用的一条链路
我们可以将 Tauri 的架构拆解为四个主要层级：前端、桥接、运行时、上游底座。
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并生成配置结构；同时负责资源嵌入、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：给前端提供 cjs/esm/ts 的调用入口，用于在 WebView 中与宿主通信（事件、窗口、webview、fs 等能力会以模块方式组织）。
- CLI：核心 CLI 是 Rust 可执行文件，通过 napi-rs 做成 npm 平台包，前端生态里安装使用更顺滑。
- Bundler：负责面向目标平台构建与打包，把前端静态产物、Rust 外壳、图标、签名、安装包串成可分发成品。
- create-tauri-app：脚手架把前端模板、Tauri 配置、目录结构一次性搭好。
5. Upstream：TAO 与 WRY 为什么这么关键
很多人只记得用系统 WebView，但忽略了背后两个核心事实：WebView 需要一个可靠的事件循环与窗口抽象，且各平台 WebView 行为差异大，需要统一封装。
TAO 就是跨平台窗口与事件循环的统一入口；WRY 是跨平台 WebView 渲染与宿主交互的统一入口。Tauri 在它们之上构建应用框架层。
6. 插件模型：扩展能力的标准姿势
插件通常包含三件事：
- Rust 侧实现某种能力
- 提供集成胶水（初始化、配置、权限、生命周期）
- 暴露 JS API，让前端易用地调用能力
因此插件既是能力扩展点，也是团队治理点：你可以把敏感能力（文件系统、密钥、数据库等）集中在插件层，并通过配置与 capability 机制做默认拒绝、按需开放。
7. 架构理解后的落地建议
若要将架构优势转化为实际的项目可维护性，建议把握以下三个核心方向：
- 前端只负责 UI 与状态：把系统能力调用集中收口（少量 invoke/事件），不要到处散落调用。
- Rust 侧做边界与治理：参数校验、权限控制、路径规范化、敏感操作审计日志，尽量放在后端命令/插件里。
- 编译期配置驱动能力裁剪：能关的 API/插件就关掉，减少攻击面与复杂度，这也是 Tauri 强项之一。
