后端模式
Standalone（Supabase）与 Unified（Soar API）：如何选择、模式如何解析，以及哪些东西不能混用。
模板在同一套业务契约之后内置了两个完整后端。一个构建装配哪一个是在打包 前通过环境变量做出的构建级选择——一个安装实例只会对着一个后端认证和存 取数据，不存在面向终端用户的切换开关。
| Standalone Mode | Unified Mode | |
|---|---|---|
SOAR_BACKEND_MODE | supabase（默认） | soarApi |
| 认证 | Supabase Auth | Better Auth（/api/auth/*，Bearer token，仅 Rust 原生侧） |
| 数据 | PostgREST + RLS | Soar App API（/api/app/v1/*） |
| Session 存储 | OS Keychain 命令 | Rust 私有 Keyring 命名空间 |
| 计费 | Creem Web Checkout | 宿主管理的订阅快照、Checkout 与门户 |
| OAuth / 设备 Token / 测试推送 | 见 Standalone 文档 | 未实现——能力驱动的 UI 会隐藏这些操作 |
| 与 Web 应用共享用户/数据 | 否 | 是——与兼容 Web 宿主共享同一个后端 |
Standalone Mode 是经典的单模板形态：桌面应用直连你的 Supabase 项目。 如果你只购买了 Tauri 模板，用这个模式即可，它的行为没有任何变化。
Unified Mode 让应用改为指向兼容 Web 宿主的
Soar App API。Web 和桌面端共享同一个 Better Auth
用户、同一张 todos 表、同一份 Profile 和同一行
订阅记录。所有 Unified 网络请求都在
Rust：Webview 通过类型化命令只拿到业务 DTO 和脱敏后的 Session——永远接
触不到 Bearer Token、Authorization header 或 presigned URL。
从这里开始
先定模式，然后只跟一份对应的配置指南走：
Standalone：Supabase Setup
创建 Supabase 项目：Schema、认证回调、Edge Functions 与密钥。
Unified：Soar API Setup
连接兼容宿主：Rust 配置、宿主环境、Session 与验证。
还没想好选哪个？平台级的模式指南和 兼容性矩阵从产品维度逐项对比了两种部署。
模式如何解析
SOAR_BACKEND_MODE 在构建时注入为编译期常量，由 Webview
（shared/platform/backend-mode.ts）和 Rust 侧
（src-tauri/src/build_env.rs）共享：
soarApi→ Unified Mode。supabase或未设置 → Standalone Mode。- 其他任何值都会让启动失败（"SOAR_BACKEND_MODE must be either supabase or soarApi"）——写错值不可能悄悄选中某个后端。
暴露给 Webview 的只有模式本身；SOAR_API_BASE_URL 与 SOAR_AUTH_ORIGIN
只存在于 Rust 原生侧。Webview 代码只依赖业务契约，不包含任何后端类型
判断。
没有静默回退。 如果选择了 Unified Mode 但 SOAR_API_BASE_URL 缺失或
格式不对，Soar API 路径会以可诊断的配置错误失败——绝不会转而初始化
Supabase 后端。错误的后端配置应当不可能被忽视。
两种模式不能混用
每个后端都是独立的身份源。Supabase 会话无法调用 Soar App API，Better Auth 会话也读不到你的 Supabase 表——设计上不存在桥接、双写或从一个模式回退 到另一个：
- Auth、数据、存储和订阅永远来自同一个后端预设。不可能用 Supabase 登录 却经 Soar API 存 todos。
- 一个模式里创建的用户在另一个模式里不存在。同一邮箱在两边注册是两个毫 不相关的账户。
把生产应用切换模式是一次数据迁移，不是改一行配置。 对已有安装群翻转
SOAR_BACKEND_MODE 意味着：把用户账户迁入新身份源（用户必须重新认证——
密码哈希不会自动转移）、搬迁 todos、Profile 和已上传文件、并把计费身份重
新指向新的用户 ID。请在上线前按部署确定模式；之后的切换要当作一个有计划
的迁移项目。