App 端数据存储统一为文件优先

[typed-sigterm]

统一是否 portable 的行为；出现未知错误时可直接给出文件路径

与 localStorage 的同步参考当前 portable 版的实现

[Luyicheng-Agent]

读了下当前存储相关代码，先把自己理解到的现状梳理一遍，再针对 issue 的三点分别回应，最后给几种方案供 @typed-sigterm 参考。如果有理解错的地方还请指正。

当前存储实现现状

仓库里同时存在三种运行模式，由 __APP__（src/utils/app.ts:31）和 isPortable()（src/utils/app.ts:34-42）区分：

1. Web 端（__APP__ === false，Cloudflare Pages 部署）

   • 配置 / 名单 / 分组全部走 localStorage：config 通过 useLocalStorage 包装（src/stores/config.ts:10），名单/分组直接 localStorage.getItem/setItem（src/utils/namelist.ts:25-37、src/utils/group.ts:15-29）。
   • 主题资源（背景图）无文件存储，loadLocalFile 在非 App 环境会抛 createNotInAppError（src/utils/fs.ts:81-82）。

2. Tauri 桌面版 - installed（非 portable）（__APP__ && !isPortable()）

   • config / 名单 / 分组仍然只走 localStorage，与 Web 端一致；getRawConfigSnapshot / clearConfig 也走 localStorage 分支（src/utils/config.ts:65-77）。
   • 仅主题资源走文件，目录由 getDataDir() 返回 BaseDirectory.AppData（src/utils/fs.ts:9-13），主题属性用 useJsonFile 写到 theme/properties.json（src/stores/theme.ts:57-61）。

3. Tauri 桌面版 - portable（__APP__ && isPortable()）

   • 判定逻辑：非 DEV 且 ./installed 资源不存在（src/utils/app.ts:39-41）；installed 在 tauri.conf.json:26-28 作为 resource 打包，installed 版有该文件、portable 解压版没有。
   • 数据文件 ./data.json（PORTABLE_DATA_FILE，src/utils/config.ts:35），通过 Rust 命令 read_file / write_file 读写（src-tauri/src/main.rs:10-31），路径用 resolveResource 解析到 exe 旁的 resource 目录（src/utils/app.ts:50-60）。
   • 同步逻辑在 initPortable()（src/utils/fs.ts:97-120）：启动时 file → localStorage 全量覆盖；运行时监听 window.storage 事件，localStorage 变更即把整个 localStorage 序列化写回 file（但 storage 事件单窗口下不会触发，详见下文 (3) 的局限说明）。由 app.vue:80-84 在 onMounted 中调用。
   • 主题资源改走 BaseDirectory.Resource（getDataDir() 在 portable 下返回 Resource）。

package.json 中未依赖 unstorage 或类似统一存储库（grep 全仓无匹配），目前所有存储都是手写的 localStorage / Tauri FS 调用。

针对三点诉求的回应

(1) 统一是否 portable 的行为

当前 portable 与非 portable 桌面版的本质差异其实只在「config/名单/分组是否有一份文件镜像」：portable 用 resolveResource('./data.json')（解析到 exe 旁的 resource 目录）做 localStorage 的持久化后端，installed 版则完全没有这层文件，数据只在 webview 的 localStorage 里。getDataDir()（src/utils/fs.ts:9-13）和 getRawConfigSnapshot/clearConfig（src/utils/config.ts:65-77）里 isPortable() 分支就是这个差异的集中体现。「统一」如果理解为「让 installed 桌面版也把 config/名单/分组落到文件」，那主要工作就是把 portable 的同步逻辑搬到 AppData 目录下复用一次。

(2) 出现未知错误时给出文件路径

目前的错误处理比较稀薄：src/stores/config.ts:11 的 UserConfigSchema.parse(ret.value) 若 schema 校验失败会直接抛 ZodError，没有 try/catch，会让 store 初始化失败；readPortableData()（src/utils/app.ts:50-54）的 JSON.parse 没有针对「文件内容被改坏成非法 JSON」的 try/catch 兜底（空文件/文件不存在已由 || '{}' 配合 Rust 端 read_file 返回空串处理，见 src-tauri/src/main.rs:13-15，但非法 JSON 仍会抛错）。要实现「给出文件路径」，可以：(a) 在 config store 初始化外层包 try/catch；(b) catch 时按当前模式解析数据文件绝对路径——portable 用 resolveResource(PORTABLE_DATA_FILE)、installed 桌面版用 AppData 下的对应文件、Web 端无路径只能提示 localStorage；(c) 通过 naive-ui dialog 把路径展示给用户并支持「打开所在目录」。这件事和 (1) 强耦合：只有 installed 桌面版也落文件后，「给出文件路径」才对所有桌面用户普遍可用。

(3) localStorage 同步参考 portable 版

portable 版当前做法就是 initPortable()（src/utils/fs.ts:97-120）：启动 file → localStorage 全量覆盖，运行时 storage 事件触发 localStorage → file 全量序列化。如果 installed 桌面版要复用，把底层 readPortableData/writePortableData（src/utils/app.ts:50-60）从 invoke('read_file') 换成 @tauri-apps/plugin-fs 的 readTextFile/writeTextFile + BaseDirectory.AppData 即可，逻辑可基本原样复用。但有一个容错差异需要注意：Rust 端 read_file（src-tauri/src/main.rs:13-15）对文件不存在做了特殊容错（返回空字符串），而 readTextFile 在文件不存在时会抛错；installed 桌面版首次启动时 AppData 下并没有 data.json，复用时需要补 exists() 预检或 try/catch 兜底首启。一个已知的局限：storage 事件只在其他文档触发（同窗口 setItem 不触发），所以单窗口下运行时同步其实只发生在启动时；如果希望真正实时落盘，可能要把 storage 事件换成对 config store 的 watchDeep 主动写文件。

架构建议

列出三个层次递进的方案，复杂度递增：

• 方案 A（最小改动，推荐作为第一步）：把 initPortable 泛化成 initFileBackedLocalStorage(filePath, baseDir)（同时把内部调用的 readPortableData/writePortableData 参数化为接受 filePath/baseDir 的读写函数），让 installed 桌面版在 onMounted 里也调用一次（写到 AppData/ex-caller/data.json），Web 端不调用。仍然以 localStorage 为运行时唯一 API，文件只是持久化镜像。改动小、与现有 portable 行为完全一致、风险低；缺点是没有真正统一存储 API，只是把 portable 的镜像机制推广。

• 方案 B（薄适配层）：自研一个同步 Storage 接口（getItem/setItem/removeItem），Web 端实现直接代理 localStorage，Tauri 端实现内部维护「内存缓存 + 启动加载 + watchDeep 落盘」。零依赖，可保持与 useLocalStorage 兼容（仍是同步读内存）；缺点是要自己处理文件 IO 错误和并发，首启异步加载完成前内存缓存尚未就绪的时序也需要单独处理（首次同步读拿到初值、异步加载完后再回填 ref）。

• 方案 C（引入 unstorage）：用 unstorage 作统一抽象，Web 端挂 localStorage driver、Tauri 端挂 FS driver。优点是成熟、driver 丰富、未来扩展（IndexedDB、远程同步）容易；缺点是 unstorage 是异步 API，与现在 useLocalStorage 的同步响应式模式不兼容，config store 需要改成 async 初始化，改造面较大，且新增依赖。

考虑到 issue 提到「参考当前 portable 版的实现」，似乎倾向渐进式。我个人倾向方案 A 作为第一步，先把 installed 桌面版的文件镜像补上、把错误兜底 + 路径提示加上；待这层稳定后再评估是否值得上 B/C。

想请教下 @typed-sigterm ：你倾向走 A 这种最小改动、保留 localStorage 为运行时核心，还是想借这次机会引入 unstorage（方案 C）把存储 API 一次性统一掉？另外「统一是否 portable」是想让 installed 桌面版也保留文件（更接近 portable），还是反过来让 portable 也只在 AppData 落文件、不再放 exe 旁边？这个方向会决定文件路径的具体取法。