现有文件管理架构的问题梳理

本文档记录当前版本文件管理架构中已识别的问题与风险，便于后续规划改造。

1. 职责边界割裂

• 物理文件由 main 进程落地与管理。
• 逻辑引用与计数由 renderer 进程在 db.files 中维护。
• 两者之间缺乏原子性与一致性保障，容易出现“文件已落地但引用未写入”或“引用存在但文件缺失”的状态。

2. 上传与登记非原子

• uploadFile 在 main 完成文件写入后，renderer 再写入 db.files。
• addFile 可绕过 main 直接登记引用。
• 这导致并发上传、异常中断时计数不准确或引用缺失。

3. 渲染进程可直接写入文件引用

• renderer 侧可直接调用 addFile 写入 db.files。
• 若 FileMetadata.path 未经过 main 管理，可能指向不存在或不可访问的文件。
• 这既是权限风险也是一致性风险。

4. 去重对用户可见性冲突

• 当前去重以“大小 + 内容 MD5”为准。
• 对用户而言，同内容不同文件名无法被区分为不同文件。
• 这与“用户视角文件应独立存在”的需求冲突。

5. 引用计数语义不足

• count 是引用计数，但引用关系本身并不显式。
• 难以在迁移时精确还原“引用粒度”的文件节点。
• 难以解释某个文件被哪些业务对象引用。

6. 缺少结构化目录树

• 当前文件列表以类型/时间/大小排序，不具备应用内目录树。
• 若要引入目录树，需要重新定义“文件节点”与“目录节点”的关系。

7. 业务来源不可区分

• 知识库上传文件、对话上传文件统一落入扁平化存储。
• 文件页面无法区分业务来源或上下文，缺少组织维度。
• 笔记相关文件未纳入文件页面展示，导致可见性不一致。

8. 对话上传无法复用内部文件

• 在首页对话输入中，用户只能从 OS 选择文件上传。
• 已上传到应用内部的文件无法直接在对话中引用或复用。
• 造成重复上传与用户体验割裂。

9. 笔记文件管理与全局文件管理割裂

• 笔记文件树独立管理，未纳入 db.files 体系。
• 与对话/知识库等文件管理路径完全分离，缺少统一入口与一致性保障。
• 对用户而言，文件能力表现不一致（文件页不可见、来源不可追溯）。

10. 笔记文件树未纳入 DB 管理

优点：

• 直接映射真实文件系统，外部编辑器可无缝协作。
• 无需额外索引或迁移，结构简单。
• 变更监听可直接基于目录扫描与文件监控。

问题：

• 与 db.files 体系割裂，无法统一检索与展示。
• 业务维度难以叠加（来源、标签、引用关系）。
• 一致性依赖监听与扫描，逻辑分散在页面中。
• 未来引入“单一节点表 + 文件树”需要重新建模或双向同步。

11. 跨进程一致性难以验证

• 主进程与渲染进程缺少统一的“文件写入 + 引用登记”事务。
• 目前也缺少统一的校验或修复机制（如启动时对齐磁盘与 DB）。

12. 可扩展性受限

• 现有 FileMetadata 结构与 db.files 表不易扩展到“单一节点表 + 文件树”模型。
• 迁移需要同时处理物理文件、引用计数、业务引用数据（messages/knowledge/paintings）。

13. FileMetadata 生产不统一

• ext/type 的生成分散在多个入口，存在不一致策略。
• main 侧通过扩展名与文本检测推断类型，renderer 侧多处直接使用 MIME 或字符串拼接。
• 缺少统一入口与规范，容易导致展示与过滤行为不一致。

结语

以上问题说明当前架构更像“物理存储 + 轻量引用计数”的混合实现，后续若引入“单一节点表 + 文件树”，需要明确主进程统一入口与引用粒度的迁移策略。