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

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

## 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 或字符串拼接。
- 缺少统一入口与规范，容易导致展示与过滤行为不一致。

## 结语

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