人人都会AI编程

14.1 企业级项目目录架构设计

更新时间：2026-07-11

一个能在企业环境中长期维护的 Tauri 项目，不能只靠初始化时的默认模板。合理的目录架构需要考虑到多人协作、多环境配置、自动化构建、代码复用和安全性。以下是一个经过实际项目验证的推荐目录结构，它不仅清晰分层，还能随着业务增长自然扩展。

my-tauri-app/
├── src/                         # 前端源码（Vue/React/Svelte 等）
│   ├── assets/                  # 静态资源（图片、字体）
│   ├── components/              # 公共 UI 组件
│   ├── pages/                   # 页面级组件
│   ├── api/                     # 与 Tauri 后端通信的封装函数
│   ├── stores/                  # 状态管理（Pinia/Zustand 等）
│   └── main.ts                  # 前端入口文件
│
├── src-tauri/                   # Tauri Rust 后端
│   ├── src/
│   │   ├── main.rs              # Rust 入口，启动应用
│   │   ├── lib.rs               # 插件注册、命令导出
│   │   ├── commands/            # 所有 IPC 命令（按模块分文件）
│   │   │   ├── mod.rs
│   │   │   ├── file.rs
│   │   │   └── user.rs
│   │   ├── models/              # 数据结构定义（请求/响应体等）
│   │   ├── services/            # 核心业务逻辑（独立于 IPC 层）
│   │   ├── utils/               # 工具函数（如加密、文件操作封装）
│   │   └── migrations/          # 数据库迁移脚本（如果用 SQLite 等）
│   │
│   ├── icons/                   # 应用图标（各平台格式）
│   ├── capabilities/            # 权限能力声明（Tauri v2+）
│   │   └── default.json
│   ├── tauri.conf.json          # 应用核心配置（窗口、包名、安全策略等）
│   ├── Cargo.toml               # Rust 依赖和项目元信息
│   └── build.rs                 # 构建脚本
│
├── packages/                    # 可选：monorepo 共享包（如通用类型定义、工具库）
│   ├── shared/                  # 前后端共享的类型或常量
│   └── ui-lib/                  # 抽取的 UI 组件库
│
├── scripts/                     # 构建/发布/签名等自动化脚本
│   ├── build-ci.sh
│   └── sign-win.bat
│
├── .github/                     # CI/CD 工作流（GitHub Actions 示例）
│   └── workflows/
│       ├── lint.yml
│       └── release.yml
│
├── .env.development             # 开发环境变量（不提交密钥）
├── .env.production              # 生产环境变量
├── .gitignore
├── package.json                 # 前端依赖和脚本
├── vite.config.ts               # 前端构建配置
└── README.md

为什么这样设计？

1. 前后端清晰分离
src/ 完全负责 UI，src-tauri/ 完全负责原生逻辑。这种隔离使得前端工程师可以独立开发，Rust 开发者也能专注业务，冲突极少。前端通过 api/ 目录统一封装 invoke 调用，避免到处散落原生调用代码。

2. Rust 端的模块化

  • commands/ 只负责接收前端调用、参数校验和返回结果，不写业务逻辑。这样做的好处是：命令可以被独立的测试，业务逻辑可以脱离 Tauri 上下文复用。
  • services/ 是真正的核心，比如文件解析、加密、数据库操作。如果以后需要移植到其它 Rust 项目，直接抽取这个目录即可。
  • models/ 集中定义结构体，便于序列化和跨模块共享。

3. 权限与配置外置
在 Tauri v2 中，权限不再硬编码在代码里，而是声明在 capabilities/ 中的 JSON 文件。单独目录管理权限，一目了然，审计时也方便。tauri.conf.json 只保留必要配置，窗口、安全策略等与环境无关的配置放在这里，环境相关的（API 地址、密钥路径）用 .env 文件管理，且不提交到仓库。

4. 企业级扩展：monorepo 与共享代码
如果有多个前端应用（比如一个桌面端、一个管理后台），packages/ 可以容纳共享的类型定义、工具函数甚至 UI 组件。结合 npm workspaces 或 pnpm workspaces 管理，避免代码重复。

5. 构建与 CI/CD 友好
scripts/ 保存各平台的构建脚本、代码签名指令，新成员加入时不必再从 README 里复制难懂的终端命令。.github/ 内的流程保证每次 PR 都经过 lint、测试，发布时自动生成多平台的安装包。

6. 安全建议

  • 将敏感操作（如文件系统读写）集中到少数几个命令中，并在 capabilities 中明确限定作用域。
  • 前端发送的 invoke 调用，参数永远使用强类型校验，不信任任何前端输入。
  • 在 tauri.conf.json 中开启 CSP（内容安全策略），限制 WebView 能加载的资源。

从简单到复杂都能驾驭

这个目录结构既适用于初创小工具，也能支撑大型企业项目。刚开始时，你可以只保留 src、src-tauri 和配置文件；随着功能增加，逐步加入 services、models 和 scripts，而不会经历痛苦的“重构目录”过程。清晰的分层比死板的规则更重要——让每一个文件都能被猜到该放在哪里，是目录设计的终极目标。