数据生命周期

一个常见问题是：什么会让 data.json 变大，什么会让它缩小，是否需要手动清理？简短答案是：无需手动清理。下面是它的工作方式。

数据存放在哪里

本地数据的事实来源是应用数据目录中的 SQLite 数据库。同步文件夹里的 data.json 是应用根据该数据库反复重写的快照。它既是同步载荷，也是便于人工阅读的备份，而不是只增不减的日志。

因为文件会被重写，其大小可能在两次运行之间减小：过期的删除标记和已彻底清除的项目只是不再写入。删除 data.json 并不会“压缩”任何东西；应用只会根据数据库重新生成相同的快照。

什么会让它变大

• 活跃、已完成和已归档的任务（历史记录默认可搜索）
• 项目、分区、领域、人员和已保存筛选器
• 附件元数据（每个附件几百字节；文件本身另存于 attachments/）
• 已删除项目的删除标记，用于让其他设备得知删除操作

什么会自动让它缩小

• 删除标记到期：删除记录会在保留期后清除（默认 90 天）。
• 清空垃圾桶：“永久删除”（逐项或全部清空）会立即移除数据，只保留删除标记直至保留期结束。
• 附件清理：系统会通过有次数上限的重试，清理失去关联的附件元数据和过期的待传输记录（“设置 → 数据”中也可手动清理）。
• 可选归档保留期限：“设置 → 数据 → 归档保留期限”默认为永不。确认正整数天数后，符合条件的已归档任务和项目会在期限届满后永久删除。启用或缩短期限需要确认；补上归档时间的旧记录先获得完整保留期，活跃项目、较新内容和并发编辑会阻止提前清理。此设置和删除标记会同步，但备份及服务商历史记录独立保留。

为什么使用单个文件，而不是拆分归档

已归档任务有意保留在同一个同步文档中。文件后端（WebDAV、文件夹、Dropbox）会分别上传各个文件。若把活跃和已归档数据拆到不同文件，归档与取消归档就会成为双文件事务，可能只完成一半，导致设备间数据分歧。单个文档能作为一个原子单元合并。长期的载荷优化计划是在现有修订元数据之上实现增量记录同步，而不是增加更多文件。合并规则请参阅同步算法。

实际容量预期

正常使用多年后的任务数据通常只有几百 KB 到几 MB；如果你添加文件或音频附件，相比 attachments/ 文件夹仍然很小。如果快照看起来过大，请清空垃圾桶，在设置 → 数据中运行附件清理，并先检查 attachments/，不必急着担心 JSON。