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-tauriRust 工程这是 Tauri 的“应用外壳 能力层”src-tauri/是一个标准 Cargo 项目只是比普通 Rust 项目多了几类 Tauri 专用文件夹/配置文件。2.1 tauri.conf.jsonTauri 的总控配置中心它是最核心的配置文件典型会包含应用 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 5173Tauri 窗口加载 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 暴露最小能力面所有权限控制、输入校验、文件路径规范化都放 Rustcapabilities把“能调用什么”当成发布治理点代码评审时重点看它有没有被滥开