桌面端必懂基础
给新手准备的桌面应用基础知识：Tauri、窗口、本地权限、存储、签名和自动更新
桌面应用就是”一个带系统能力的本地窗口”。界面还是用 React 写，后端还是复用 01MVP Web/API，但多了本地 runtime：读文件、打开目录、托盘常驻、自动更新、系统权限和安装包。
新手最容易低估的点：桌面端不是套个壳就完事。只要你要发给真实用户，本地权限、存储位置、签名、公证和更新都得认真搞。
核心要点
界面仍然是前端
React 负责窗口里的页面、按钮、表单和数据展示。
系统能力要走 Tauri
文件、托盘、打开目录、进程和权限，不应该直接当成普通网页能力。
发布是工程问题
DMG、EXE、签名、公证、更新端点，都要在发布前纳入验收。
发布前会遇到哪些账号和证书
桌面端可以很快跑起 UI，但公开分发时会遇到平台信任问题。用户电脑会问：这个安装包是谁发的、有没有被篡改、能不能自动更新。
| 名称 | 用途 | 什么时候准备 |
|---|---|---|
| Apple Developer Program | macOS Developer ID 签名、公证、Gatekeeper 信任、Mac App Store | 准备公开发 macOS 安装包前 |
| Windows 代码签名证书 | 给 .exe / .msi 安装包签名，降低安全警告 | 准备公开发 Windows 安装包前 |
| GitHub Releases / R2 / 文件服务器 | 托管安装包、更新文件和 changelog | 做下载页或自动更新前 |
| 自己的域名 | 下载页、API、隐私政策、自动更新端点 | 真实分发前 |
| Microsoft Partner Center | 上架 Microsoft Store 时使用 | 只在选择商店分发时需要 |
内部测试可以先跳过签名和商店，直接生成安装包给自己或团队验。但只要面向真实用户，签名、公证和更新路径就要进入发布计划。
一张图看懂桌面端
关键是中间两层。普通网页没有 Tauri runtime，不能随便读写用户电脑。模板把”界面”和”系统能力”分开，这样调试时更容易定位问题出在哪一层。
先搞懂这 7 个概念
| 概念 | 新手理解方式 | 为什么重要 |
|---|---|---|
| Tauri | 把 Web 前端变成桌面应用的框架 | 让 React 界面拥有本地窗口和系统能力 |
| Window | 用户看到的应用窗口 | 尺寸、标题、全屏、关闭行为都要配置 |
| Command | 前端请求本地能力的入口 | 例如打开 app data 目录、读写配置、调用系统功能 |
| Capability | Tauri 的权限清单 | 限制前端能调用哪些本地能力 |
| App Data | 应用自己的本地数据目录 | 适合放偏好设置、缓存、离线资料 |
| Keychain | 系统级安全存储 | 适合放 token、敏感凭据，后续产品可按需接入 |
| Updater | 自动更新机制 | 用户安装后，不应每次手动下载安装包 |
Tauri 官方文档把桌面应用拆成前端、Rust 后端、配置和能力边界几部分。你不用一开始就精通 Rust，但要知道系统能力不能散落在页面里。
浏览器预览和 Tauri 真机窗口
浏览器预览适合做什么
- 看页面布局
- 调按钮、表单、普通 API
- 快速检查 Tailwind 样式
- 让没有 Rust 环境的人先看 UI
Tauri 原生窗口必须验证什么
- 本地 command 是否可用
- capabilities 是否放行
- 托盘、窗口、打开目录是否正常
- 打包后的安装包是否可启动
浏览器能跑通，不等于桌面端完成。浏览器只能说明 UI 和网络请求大概没问题；Tauri command、系统权限、安装包和自动更新必须在原生窗口或打包产物里验。
改造顺序
先改应用身份：产品名、identifier、窗口标题、图标、Bundle 信息和安装包显示名。
再接 Web/API：配置 VITE_DESKTOP_SERVER_URL，验证 health、登录、profile 和会员状态。
再加本地能力：每新增一个系统能力，都同步更新 Tauri command、capability、前端 adapter 和验收说明。
最后做发布工程：签名、公证、安装包、自动更新端点和多平台 QA 一起处理。
复制给 AI
当你要把模板改成自己的桌面应用，把这段发给 AI：
请帮我把 01MVP desktop 模板改成我的桌面应用。产品名称是「这里填名称」，核心功能是「这里填一句话」，目标平台是 macOS / Windows / Linux。
请先检查 products/01mvp/apps/desktop 的当前结构，再按这个顺序执行：
1. 替换应用名称、identifier、窗口标题、图标和 Tauri 配置。
2. 检查 VITE_DESKTOP_* 环境变量，并确认后端允许桌面端 origin。
3. 验证 health、登录、profile 和会员状态都通过现有 01MVP Web/API 调用。
4. 保留 runtime adapter，不要在页面里直接散写 Tauri 调用。
5. 如果新增本地能力，同步更新 Rust command、capability、前端 adapter 和文档。
6. 运行桌面端可用的 lint、type-check、test、cargo check、tauri build 或替代检查，并汇报结果。如果你的应用需要全局快捷键、截图、文件监听、后台任务、Keychain 或自动更新，把这些作为独立任务交给 AI。系统能力越多，越要分批验证。
常见坑
| 坑 | 正确做法 |
|---|---|
| 把所有 Tauri 调用写进页面 | 放进 runtime adapter，页面只调用清晰的方法 |
| 浏览器预览通过就认为桌面完成 | 原生窗口、command、capability、安装包都要测 |
| 本地数据乱放 | 偏好和缓存放 app data，敏感凭据后续接 Keychain |
| 忽略签名和自动更新 | 真实分发前要准备证书、公证、更新端点和回滚方案 |
| 一次性加入太多系统权限 | 每个权限单独说明、单独配置、单独验收 |
继续阅读
桌面端快速开始
跑起浏览器预览和 Tauri 原生窗口。
项目结构
看懂前端、runtime adapter、Rust commands 和配置边界。
Runtime 与权限
新增系统能力前先理解 Tauri capability。
构建与分发
处理安装包、签名、公证和平台分发。
官方参考
这篇文档有问题？