MemoFlow · Account / Desktop Profile 开发笔记

按版本记录离线 SQLite 账号、Electron IPC、本地 Profile 与云端认证同步方案。

#blog #growing #dev

Account 模块目标

我希望桌面端在没有网络时也能正常使用，连接云端之后又可以登录、同步和继续操作。因此 Account 不能只照搬 Web 登录流程，得先考虑 Electron 主进程里的本地数据和渲染进程如何通信。

第一版把 Electron 主进程当作本地后端，Vue 渲染进程当作客户端。选择 SQLite 保存用户与业务数据，主进程封装 Model、Service 和 IPC，渲染层通过服务接口调用，而不是直接碰数据库。

本地账号暂时使用用户名与密码，先保存最基本的账号信息。SQLite 的优势是无需额外启动服务器、部署简单，又适合单机事务性数据；不过需要由主进程统一管理连接和访问，不能让任意渲染组件自行操作数据库。

这版优先实现离线登录、获取资料和业务调用流程。

现在需要联网能力。初步想法是：用户从本地账号开始使用，选择同步时注册云端账号，并获得独立的在线身份；本地走 IPC，在线走 HTTP。

两种 Transport 可以共用相似的 Application 接口，但IPC 与 HTTP 只是通信方式，不能直接推导出本地身份和云端身份天然一一对应。

如果把“是否联网”直接写成 Account 的一个状态，之后切换用户、断网、退出登录和账号合并都会很难处理。所以需要进一步划清本地数据容器与云端登录会话。

这版采用 Desktop Local Profile + Cloud Auth 的模型。

本地 Profile 是一份真正独立的数据容器，有稳定的 profileId、本地数据库和 Vault。Guest 也可以离线创建和修改自己的资料；是否能打开这份本地数据由 Profile Access/Unlock 决定。

云端登录交给 Better Auth，负责邮箱、验证状态和 Session；Account 只负责产品展示资料。登录会话有效与本地 Profile 已解锁是两个不同的判断，不能再共用一个笼统的 isAuthenticated。

现在考虑 Guest 要连接云端账号的情况。

连接云端不应该把已有本地资料、Vault 和文件目录换成另一套空容器。方案是保留原来的 profileId 与本地资源，通过明确的 CloudBinding 和 Owner Adoption 将业务身份与云端账号联系起来。

如果目标云端账号已经绑定同一设备的另一个 Profile，不自动静默合并。退出云端登录也只影响在线能力，不应该删除或锁住用户本地数据。

资料编辑与同步也需要明确权威：Desktop 的用户资料先在当前本地 Profile 数据库中保存，已经绑定云端时再通过带修订版本的 Outbox 异步交付。断网时保留待发送的修订，不需要为了等待服务端而阻塞本地编辑。

还要把几个操作分开：退出云端登录、锁定本地 Profile、关闭云端 Account、删除本地 Profile，分别对应不同的生命周期，尤其不能把退出登录等同于清除本地知识库。

这样本地优先和在线同步可以共存，而不必把“离线账号”简单当作一个等待升级的云端账号。