后端模式
Standalone（Supabase）与 Unified（Soar API）：如何选择、模式如何解析，以及哪些东西不能混用。
模板在同一套业务契约之后内置了两个完整后端。一个构建装配哪一个是在打包 前通过环境变量做出的构建级选择——一个安装实例只会对着一个后端认证和存 取数据，不存在面向终端用户的切换开关。
| Standalone Mode | Unified Mode | |
|---|---|---|
SOAR_BACKEND_MODE | supabase（默认） | soarApi |
| 认证 | Supabase Auth | Better Auth（/api/auth/*，Bearer token，仅主进程） |
| 数据 | PostgREST + RLS | Soar App API（/api/app/v1/*） |
| Session 存储 | safeStorage 加密存储 | 按 API Origin 与 Channel 隔离的私有 safeStorage 命名空间 |
| 计费 | Creem Web Checkout | 宿主管理的订阅快照、Checkout 与门户 |
| OAuth / 设备 Token / 测试推送 | 见 Standalone 文档 | 未实现——保持缺失而非近似模拟 |
| 与 Web 应用共享用户/数据 | 否 | 是——与兼容 Web 宿主共享同一个后端 |
Standalone Mode 是经典的单模板形态：桌面应用直连你的 Supabase 项目。 如果你只购买了 Electron 模板，用这个模式即可，它的行为没有任何变化。
Unified Mode 让应用改为指向兼容 Web 宿主的
Soar App API。Web 和桌面端共享同一个 Better Auth
用户、同一张 todos 表、同一份 Profile 和同一行
订阅记录。所有 Unified 网络请求都在
主进程：Renderer 通过类型化 IPC 只拿到业务能力和脱敏后的 Session——
永远接触不到 Bearer Token、Authorization header 或 presigned URL。
从这里开始
先定模式，然后只跟一份对应的配置指南走：
Standalone：Supabase Setup
创建 Supabase 项目：Schema、认证回调、Edge Functions 与密钥。
Unified：Soar API Setup
连接兼容宿主：主进程配置、宿主环境、Session 与验证。
还没想好选哪个？平台级的模式指南和 兼容性矩阵从产品维度逐项对比了两种部署。
模式如何解析
SOAR_BACKEND_MODE 在构建时注入为编译期常量（__BACKEND_MODE__），由主进
程、Preload 和 Renderer 共享，shared/platform/backend-mode.ts 解析一次：
soarApi→ Unified Mode。- 其他任何值——包括未设置——→ Standalone Mode（
supabase）。
app/backends/backend-factory.ts 只会懒加载恰好一个后端图——未选中的
后端在打包构建里永远不会执行模块级初始化。Renderer 代码只依赖业务契约，
不包含任何后端类型判断。
没有静默回退。 如果选择了 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。请在上线前按部署确定模式；之后的切换要当作一个有计划
的迁移项目。