1. 顶层（前端工程）：就是一个普通的 Web 项目
Tauri 的项目结构非常'工程化'，通常由两部分组成：
- 可选的 JavaScript/前端工程（负责 UI，最终产出静态资源）
- 必须的 Rust 工程（在
src-tauri/，负责窗口、系统能力、打包分发、安全边界）
一个典型目录结构如下：
.
├── package.json
├── index.html
├── src/
│ └── main.js
└── src-tauri/
├── Cargo.toml
├── tauri.conf.json
├── src/
│ ├── main.rs
│ └── lib.rs
└── 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/：安全模型的'许可清单'
这块非常重要，但很多人刚上手会忽略。
核心原则是：你在 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 的一些构建步骤，参与资源打包/配置生成等流程。你多数时候不需要改它，除非你做很深的构建定制。
