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）：
- 先把前端编译成静态文件（dist）
- 再编译 Rust 工程
- 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：把“能调用什么”当成发布治理点，代码评审时重点看它有没有被滥开
