项目目录结构全解

上一章我们用脚手架生成了项目，但目录里那一堆文件分别干嘛，还不清楚。Tauri 项目的核心特点，是它把「前端」和「Rust 后端」放在同一个仓库里协作。这一章就把这套结构拆开讲透。

整体：前端 + Rust 后端两层

一个典型的 Tauri 项目，顶层是前端工程（JavaScript/TypeScript 那套），src-tauri/ 文件夹里则是 Rust 工程。两者各管一摊：

my-tauri-app/
├── package.json        # 前端工程清单
├── index.html          # 前端页面入口
├── src/                # 前端源码
└── src-tauri/          # Rust / Tauri 后端工程
    ├── Cargo.toml
    ├── Cargo.lock
    ├── build.rs
    ├── tauri.conf.json
    ├── capabilities/
    │   └── default.json
    ├── icons/
    └── src/
        ├── main.rs
        └── lib.rs

你可以把 Tauri 理解成一个「静态网站托管器」：它先把前端工程编译成静态文件，再把它们塞进 Rust 程序里，最后用一个系统原生的 WebView 把页面渲染出来。所以前端的组织和你平时做网页几乎一样，真正的 Tauri 专属内容都集中在 src-tauri/。

Rust 工程的根：Cargo.toml

src-tauri/Cargo.toml 是 Rust 的包清单，声明了项目名、版本、作者，以及依赖的 Rust 包。Tauri 相关的两行最关键：

[build-dependencies]
tauri-build = { version = "2.0.0" }

[dependencies]
tauri = { version = "2.0.0", features = [ ] }

tauri 是运行时依赖，tauri-build 是构建期依赖。版本号用语义化版本（SemVer），写成 2.0.0 时，Cargo 会自动拉取最新的兼容补丁和次版本。在 src-tauri 里跑 cargo update 就能更新到最新兼容版本。

构建时还会生成 Cargo.lock，它锁死依赖的具体版本，保证你和其他人、和 CI 環境编译出一致的结果。这个文件建议提交进版本库。

主配置：tauri.conf.json

tauri.conf.json 是 Tauri 的「总开关」，从应用标识符、窗口标题，到开发服务器地址、打包设置，全写在这里。它同时也是 Tauri CLI 用来定位 Rust 工程的「标记文件」——CLI 一看到它，就知道后端在这个目录里。

这个文件内容较多，我们单独用第 11 章详细拆解。这里你只需记住它的地位：绝大多数「应用长什么样、叫什么名字、怎么打包」的问题，答案都在这一个 JSON 里。

构建脚本：build.rs

src-tauri/build.rs 是 Rust 的构建脚本，Tauri 利用它在编译前做代码生成和环境检查。标准内容只有一行：

fn main() {
    tauri_build::build()
}

你基本不用改它。它的作用是在编译阶段把配置、权限清单等信息「烧」进最终二进制，让运行时能正确加载。

入口代码：main.rs 与 lib.rs

src-tauri/src/ 下有两个 Rust 文件，分工很明确。

main.rs 是桌面端的主入口，内容极简：

#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

fn main() {
    app_lib::run();
}

它只做一件事——调用 lib.rs 里导出的 run()。app_lib 这个名字对应 Cargo.toml 里的 [lib] name 设置。

lib.rs 才是真正写应用逻辑的地方，也是移动端（Android/iOS）的入口点。它被标了 #[cfg_attr(mobile, tauri::mobile_entry_point)]，意思是：在移动端构建时，这个函数会被当作应用启动点。之所以把逻辑放在 lib.rs 而不是直接写 main.rs，是因为移动端会把你的代码编译成「库」，再由平台框架加载，桌面端则复用同一个 run()。

权限清单：capabilities/ 目录

src-tauri/capabilities/ 是 Tauri 2 新增、也很关键的一个目录。里面放的是「能力（Capability）」文件，比如 default.json。它决定了你的前端 JavaScript 能用哪些系统能力（例如调用某个 Rust 命令、访问文件系统、弹对话框）。

一句话理解：Tauri 2 默认收紧权限，前端想用某项能力，得先在 capabilities 里显式「放行」，否则调用会被拒绝。后续讲命令和插件时还会反复碰到它。

图标：icons/ 目录

icons/ 放应用图标，是 tauri icon 命令的默认输出目录，通常也被 tauri.conf.json 里的 bundle > icon 引用。脚手架生成时已经放好一套默认图标（png、ico、icns 等不同平台需要的格式），所以你一开始就能看到带图标的窗口。想换成自己的图标，把图片丢进这里、或跑 tauri icon 你的图.png 重新生成即可。

编译产物去哪了：target/ 目录

运行 tauri dev 或 tauri build 后，Rust 的编译产物会出现在 src-tauri/target/ 下。这个目录不在脚手架初始结构里，是编译时自动生成的，体积很大，通常写进 .gitignore 不进版本库。其中 target/debug/ 放开发期产物，target/release/ 放生产构建产物，打包好的安装包则在 target/release/bundle/。

理解它有助于排错：清掉 target/ 重新编译，能解决不少诡异的缓存问题；但它只是「输出地」，日常你不需要手动动它。

小结

把这套结构记熟后，你就有了「地图」：改依赖找 Cargo.toml，改应用设置找 tauri.conf.json，加逻辑找 lib.rs，配权限找 capabilities/。我们还了解了 build.rs 构建脚本、main.rs 与 lib.rs 的分工、icons/ 图标目录以及 target/ 编译产物的位置。下一章我们就钻进 tauri.conf.json 内部。