Electron 与数据库/文件系统的整合：配置、缓存与项目数据

桌面应用和纯 Web 应用最大的差异之一，是可以直接接触本地文件系统和本地数据库。
对 Electron 应用来说，这既是优势也是风险：如何在本地存储配置、缓存和项目数据，同时又保证结构清晰、安全可控？
这一篇围绕几个常见问题展开：本地文件的组织方式、轻量数据库的选型、数据迁移与清理策略。

在 Electron 应用里，本地数据大致可以归为几类：

  • 配置与偏好设置
    • 用户界面偏好（主题、语言、布局）；
    • 登录方式、默认工作目录、快捷键映射等。
  • 缓存数据
    • 索引结果（如项目文件索引、搜索缓存）；
    • 远端接口数据的本地副本；
    • 不影响核心业务，但可以提升性能。
  • 项目/业务数据
    • 本地项目结构、元数据；
    • 对某些应用来说，甚至包括主要业务数据本身（例如笔记、个人知识库等）。

这几类数据的特点和要求不同：

  • 配置数据：体量小、结构相对简单，更关注可读性与安全；
  • 缓存数据：允许失效，可以必要时全部重建；
  • 项目数据：需要更严肃的备份、迁移和一致性策略。

清晰的分类有助于在后面决定「存在哪里、用什么存、怎么清理」。

不同平台推荐的应用数据目录不同，但原则类似：

  • 使用 Electron/Node 提供的 API 获取用户数据目录（例如 app.getPath('userData') 而不是手写路径）；
  • 在该目录下按类别进一步划分：
    • config/：配置与偏好设置；
    • cache/：各种可重建缓存索引；
    • projects/ 或类似命名：应用自管的项目数据。

对于需要在用户项目目录中存放的元数据（例如 .myapp 这样的隐藏目录）：

  • 建议遵守「单一根目录」原则：
    • 不要在项目根下散落太多文件；
    • 所有应用相关文件放在一个固定子目录内，便于识别和清理。
  • 避免默认使用管理员权限（root）运行应用；
  • 对涉及敏感信息（token、私钥等）的文件：
    • 设置合适的文件权限（仅当前用户可读写）；
    • 如有必要，对内容做加密存储（结合系统密钥链或自定义加密方案）。

对于结构化程度较高、查询需求较复杂的数据，用纯 JSON 文件管理会很快碰到瓶颈：

  • 需要多条件查询与排序；
  • 希望在数据量较大时依然保持响应速度；
  • 需要一定程度的事务/一致性保证。

在这些情况下，本地嵌入式数据库是一个自然选择：

  • SQLite：成熟稳健、生态丰富、跨平台表现稳定；
  • 其他 JS 生态中的嵌入式方案（LevelDB、LokiJS 等）也有各自适用场景。

常见用法包括：

  • 缓存搜索索引、历史记录；
  • 存储本地项目元数据；
  • 为离线优先的应用提供主要存储。

在工程上，需要注意：

  • 把数据库访问逻辑集中在本地服务层，不在渲染进程中直接读写 DB；
  • 对数据库文件的路径和 schema 版本做统一管理，为未来迁移留出空间。

随着应用版本迭代，本地数据结构通常也会演进：

  • 配置项增加/重命名；
  • 数据库表或字段发生变化；
  • 缓存格式调整。

为了避免「老用户升级新版本直接崩溃」，需要有一套简单的迁移机制：

  • 在本地数据中记录一个「schemaVersion」；
  • 应用启动时：
    • 读取当前本地数据版本；
    • 根据版本差异执行相应迁移步骤（添加字段、重建索引、清理废弃数据）；
    • 迁移完成后更新版本号。

迁移逻辑应当：

  • 放在本地服务层统一管理；
  • 具备一定的幂等性与容错能力（例如失败时能回滚或安全重试）。

缓存数据和项目核心数据的区别，在于：

  • 缓存允许丢失，只要能通过重建获得；
  • 项目数据的丢失会直接影响用户。

在 Electron 应用中，建议：

  • 为缓存目录设计定期清理策略：
    • 基于时间（例如只保留最近 N 天）；
    • 基于空间（超出一定容量后按 LRU 规则清理）；
  • 为缓存重建提供明确路径：
    • 当发现缓存损坏或版本不兼容时，可以直接全量重建，而不是尝试修修补补。

在 UI 上，可以考虑：

  • 提供「重建索引」「清理缓存」之类的选项；
  • 在问题诊断/支持过程中，让用户有办法快速恢复到一个「干净但需要重算」的状态。

从安全和架构的角度，看待本地数据访问时，有一条重要原则：

  • 让渲染进程通过受控 API 访问本地数据，而不是直接调用 Node 的 fs 或数据库驱动。

具体做法可以是：

  • 在主进程或专用后台进程中实现：
    • configService、projectStore、cacheStore 等服务；
    • 暴露接口用于读写与迁移；
  • 在 preload 脚本中为渲染进程挂上有限的访问函数：
    • 例如 window.configApi.get() / set()、window.projectApi.list()；
  • 在这些 API 内部完成：
    • 参数验证；
    • 权限控制；
    • 错误处理与日志记录。

这样可以：

  • 把本地存储逻辑集中管理；
  • 为后续引入加密、备份、同步等能力预留结构空间。

可以用一句话概括这一篇：

  • 对 Electron 应用而言，本地数据库和文件系统更像是一个「运行在本机的后端」，而不是一个可以到处随手读写的共享目录。

在工程实践中，建议：

  • 明确分类配置、缓存和项目数据，并为它们设计不同的存放位置与生命周期策略；
  • 选择合适的嵌入式存储方案，并在本地服务层集中封装访问逻辑与迁移机制；
  • 让渲染进程通过受控、带约束的接口访问本地数据，为安全和长期演进打好基础。

在这样的结构下，Electron 应用既能充分利用本地存储优势，又不至于在安全性和可维护性上陷入「到处都是 fs 和 SQL」的混乱状态。