Tauri 项目结构前端壳 + Rust 内核，怎么协作、怎么构建、怎么扩展

1. 顶层（前端工程）：就是一个普通的 Web 项目

Tauri 的项目结构非常“工程化”：通常由两部分组成

• 可选的 JavaScript/前端工程（负责 UI，最终产出静态资源）
• 必须的 Rust 工程（在 src-tauri/，负责窗口、系统能力、打包分发、安全边界）

一个典型目录长这样（你贴的结构非常标准）：

. ├── package.json ├── index.html ├── src/ │ ├── main.js ├── src-tauri/ │ ├── Cargo.toml │ ├── Cargo.lock │ ├── build.rs │ ├── tauri.conf.json │ ├── src/ │ │ ├── main.rs │ │ └── lib.rs │ ├── icons/ │ │ ├── icon.png │ │ ├── icon.icns │ │ └── icon.ico │ └── capabilities/ │ └── default.json 

顶层的 package.json / index.html / src/main.js 和你做一个静态站点或 SPA 没本质区别。你可以用 Vite、Webpack、Next（需适配静态导出）、SvelteKit 等，只要最终能产出静态资源给 Tauri 加载即可。

核心心智模型：

• 你在开发模式下跑的是 dev server（热更新、调试体验好）
• 你在构建时要先把前端编译成静态文件（dist 等），再由 Rust 侧打包进应用

所以前端这部分可以自由替换，Tauri 不绑架框架。

2. src-tauri（Rust 工程）：这是 Tauri 的“应用外壳 + 能力层”

src-tauri/ 是一个标准 Cargo 项目，只是比普通 Rust 项目多了几类 Tauri 专用文件夹/配置文件。

2.1 tauri.conf.json：Tauri 的总控配置中心

它是最核心的配置文件，典型会包含：

• 应用 identifier（包名/唯一标识）
• 窗口标题、窗口行为
• dev server URL（开发模式加载哪个地址）
• 构建时静态资源目录
• 打包配置（安装包类型、签名、图标路径、权限等）

同时，它还是 Tauri CLI 定位 Rust 工程的“标记文件”。CLI 本质上就是先找到 tauri.conf.json，再按配置去启动前端、编译 Rust、打开窗口。

你在项目里最常改动的地方之一就是它。

2.2 capabilities/：安全模型的“许可清单”（命令 allowlist 的关键落点）

这块非常重要，但很多人刚上手会忽略。

一句话：你在 JS 里想调用 Rust 命令（invoke），必须在 capability 文件里允许它。
所以 capabilities/default.json 本质上就是“你的应用允许暴露哪些能力给前端”。

这套机制的价值：

• 把“前端能做什么”变成显式声明，而不是默认全开
• 更适合做企业级的权限治理与审计
• 也让你在插件/命令越来越多时不至于失控

工程建议：

• 命令按模块分组，不要一股脑全塞 default
• 对敏感能力（文件系统、执行外部命令、系统信息、网络访问等）单独 capability，方便环境隔离（dev/production、内部版/外部版）

2.3 icons/：应用图标的默认输出与引用目录

通常你会用 tauri icon 之类的命令从一张源图生成多平台图标，输出到 src-tauri/icons/，然后在 tauri.conf.json > bundle > icon 里引用。

建议：

• 源图尽量用高分辨率正方形（例如 1024×1024 PNG）
• 图标生成后别手动改一堆尺寸文件，重新生成更可控

2.4 build.rs：接入 Tauri 构建系统的“挂钩”

build.rs 一般会调用 tauri_build::build()，用于：

• 让 Cargo 在构建时执行 Tauri 的一些构建步骤
• 参与资源打包/配置生成等流程

你多数时候不需要改它，除非你做很深的构建定制。

2.5 src/lib.rs：你真正该写 Rust 业务逻辑的地方（尤其是移动端）

这里是很多人第一次看到会疑惑的点：为什么不把逻辑写在 main.rs？

原因是移动端构建方式不同：

• 移动端会把你的应用编译成 library，由平台框架（iOS/Android）加载
• 因此需要一个可复用的入口函数，放在 lib.rs 更合理
• 你会看到类似 #[cfg_attr(mobile, tauri::mobile_entry_point)] 的标记，用于移动端入口

实践结论很明确：

• 业务命令（commands）、插件初始化、状态管理等，优先写在 lib.rs
• 让桌面与移动共用同一套初始化逻辑，减少分叉

2.6 src/main.rs：桌面端入口，尽量别改

通常 main.rs 只做一件事：调用 app_lib::run()（或者你的库名对应的 run）。
文档也强调了：为了让桌面端复用移动端同一入口，main.rs 保持简单，别动它，改 lib.rs。

这里的 app_lib 对应 Cargo.toml 里的 [lib.name]，也就是你的库 crate 名。

3. Tauri 的构建流程：像“静态站点托管器”一样工作

把 Tauri 想成一个“带系统能力的静态站点宿主”会特别好理解：

开发模式（dev）：

• 启动前端 dev server（如 Vite 5173）
• Tauri 窗口加载 dev server URL
• 你改前端代码热更新；你改 Rust 代码触发重编译/重启

构建模式（build/bundle）：

1. 先把前端编译成静态文件（dist）
2. 再编译 Rust 工程
3. Rust 把静态资源打包进最终应用（并按配置输出安装包/可执行文件）

所以前端这边你要做的事情，和“发布一个静态网站”高度一致：构建产物、资源路径、路由模式（history/hash）这些依旧是关键点。

4. 如果你只想写 Rust，不要前端怎么办

可以，Tauri 也支持“纯 Rust UI/前端生态”的路线（例如 Yew/Leptos/Sycamore），甚至你可以把顶层 JS 工程完全删掉：

• 直接把 src-tauri/ 当成仓库根目录
• 或把它作为 Rust workspace 的一个 member

这时你的项目就是纯 Cargo 结构，Tauri 仍然负责窗口与 WebView，但 UI 的生成方式由 Rust 侧前端方案决定。

5. 工程落地小建议：让结构更“可维护”

如果你准备做中大型应用，我建议你从一开始就把边界划清：

• 前端：只负责 UI 与状态，不直接接触敏感能力
• Rust：用 commands 暴露最小能力面，所有权限控制、输入校验、文件路径规范化都放 Rust
• capabilities：把“能调用什么”当成发布治理点，代码评审时重点看它有没有被滥开