17ccc的数据持久化可以按“临时缓存、可靠落盘、状态快照、事务日志”划分职责：缓存负责快速读取，离线存储承接暂时无法提交的操作，快照保存可恢复状态，事务日志记录尚未完成的变更。这样设计后，应用关闭、网络中断或写入失败时，各类数据都有明确的保存位置和处理方式。
一、存储分层与数据边界
17ccc不应把所有数据都放进同一类存储。频繁变化、丢失后可重新计算的内容放在本地缓存；用户已经确认、需要跨进程保留的操作写入持久化队列；页面位置、筛选条件等恢复信息则放入状态快照。每条记录还要携带稳定标识和更新时间，避免恢复时把新旧数据混在一起。
| 存储项目 | 建议边界 | 用途 |
|---|---|---|
| 热数据缓存 | 最多200条或20 MB，缓存有效期30秒 | 加快重复读取，过期后重新载入 |
| 离线操作队列 | 最多500条，保留72小时 | 暂存未提交的新增、修改和删除操作 |
| 状态快照 | 每30秒保存一次，保留最近10份 | 恢复选中项、滚动位置和编辑草稿 |
| 事务日志 | 每笔操作单独编号，完成后清理 | 判定写入是否完成，并支持回滚 |
| 单次写入 | 超过5秒未完成即视为超时 | 触发失败处理，避免操作无限挂起 |
这些数值构成一套清晰的实现边界，而不是把缓存误当成永久记录。缓存淘汰时可以删除已经过期的热数据；离线队列则必须先确认同步完成，才能移除对应操作。两类记录采用不同的清理规则，能减少误删尚未提交内容的风险。
二、本地缓存与离线存储
缓存键应由业务对象类型和唯一标识组成，例如“记录类型＋记录编号”，同一对象的更新覆盖旧值，不应因为重复请求不断生成副本。每条缓存记录至少保存数据本体、写入时间和有效期。读取时先检查有效期；已过期的数据可以在重新载入期间作为短暂展示，但不能被当作最新结果再次写回。
离线操作则按发生顺序排队，并为每一项分配不可重复的操作编号。队列条目保存操作类型、目标对象、变更字段、创建时间和重试次数。网络恢复后，17ccc逐项提交队列：成功项标记完成，失败项保留原有顺序，稍后重试。对于同一对象连续发生的修改，可以合并为一项最终变更；新增后又删除的对象则可直接抵消，减少不必要的提交。
重试不能无限进行。一次操作连续失败达到设定上限后，应标记为待处理状态并保留错误原因，不要静默删除。用户再次编辑同一对象时，可生成新的变更并关联旧操作；最终以可确认的最新状态为准，避免重复执行造成多条相同记录。
三、状态恢复的保存与读取顺序
状态快照适合保存短期操作上下文，而非完整业务数据库。17ccc可以记录当前视图、选中对象编号、滚动位置、搜索条件和未提交草稿。快照写入时附带结构标识与保存时间；读取时先验证字段是否完整，再检查对应对象是否仍存在。对象已被删除时，恢复流程应清除失效选中项，而不是让界面停在无法操作的状态。
- 启动时读取快照：载入最近一份有效快照，恢复筛选条件、选中项与草稿。
- 校验关联对象：检查对象编号和必要字段，丢弃残缺记录，移除已经失效的选择状态。
- 处理待提交操作：读取离线队列，保留未完成项，并在连接可用时继续提交。
- 更新当前状态：以最新成功写入的记录覆盖旧快照，再恢复视图交互。
保存快照应采用临时文件或临时记录：先完整写入新快照，再一次性替换旧快照。若在写入中途关闭，启动时仍能读取上一份完整状态。草稿和滚动位置可以高频更新，体积较大的业务数据则按实际变更写入，避免每次轻微交互都复制整份数据。
四、事务回滚与一致性
涉及多项关联变更的操作，应作为一个事务处理。例如，移动一条记录时，既要更新原位置，也要写入新位置；两步不能只完成一半。事务开始前记录原值和操作编号，变更完成并校验成功后，再把事务标记为已提交。只有提交标记落盘，系统才将新状态视为最终结果。
如果写入失败或进程中断，恢复时先查看事务日志：尚未提交的事务按日志中的原值逆向撤销；已经提交的事务则保留新值，并清理残留日志。回滚本身也应可重复执行，同一事务编号即使被处理两次，也只能还原一次，避免重启后重复增加、删除或覆盖数据。
对于无法自动合并的冲突，保留原记录和待处理变更，不用较旧数据覆盖较新结果。完成提交后，再同步更新缓存和快照。按照这套顺序，17ccc的本地缓存负责速度，离线队列负责延迟提交，快照负责界面恢复，事务日志负责失败回退；四部分各司其职，数据边界明确，恢复路径也容易验证。
d4nysepv6r0a5kli9lp8xaenvxw
