用途
flutter-persistence 用于设计或审查 Flutter 应用在设备端的持久化、缓存、schema 迁移与离线同步。它的核心思路是：先根据数据形态、查询需求、持久性、敏感性、同步和迁移要求来选择存储方案，而不是先选 API。
主要能力
- 按比例选择存储：小型设置使用 preferences；文档或 blob 归属使用文件，并明确原子性和清理；当查询、关系、事务、索引或迁移足以证明必要时使用数据库；小型密钥使用平台安全存储，不把普通应用数据库当作密钥保险库。
- 保留既有包：除非某个具体需求超出其受支持的契约，否则保留已经建立的包。
- 建模归属：定义事实来源、缓存新鲜度、写入顺序、冲突行为、离线变更、删除语义，以及从损坏或不兼容数据中恢复。把存储模型放在 repository 之后，使 schema 细节不泄漏到 widget 中。
- 迁移与安全：在定义迁移和恢复行为前，先把存储状态分类为持久用户数据、持久操作、可丢弃缓存或可复现派生数据。对 schema 进行版本化，并针对真实的旧版本产物测试每条受支持的升级路径。绝不把自动销毁持久用户数据作为迁移失败的响应；重建可丢弃缓存只有在归属和重建来源明确时才有效。避免把访问令牌、密码或敏感个人数据存入日志或普通 preferences。
使用方式
在改动前，先检查 pubspec.yaml、SDK 约束、已解析的持久化包及其版本、生成 schema 的策略、现有存储归属、支持的平台和测试。
按需阅读相关子主题：
- 选择缓存键、新鲜度、失效、逐出、陈旧数据披露或用户隔离时，阅读缓存策略。
- 本地与远程数据可能分叉、变更在离线时排队、后台任务运行，或必须协调冲突和删除时，阅读离线同步。
- 在更改数据库 schema、序列化持久格式、迁移回调或不兼容数据恢复策略之前，阅读 schema 迁移与恢复。
HTTP 校验器与传输层缓存应转到 flutter-networking；图片、widget、滚动或内存缓存性能应转到 flutter-performance。
验证
测试与功能相关的首次运行、重新打开、升级、写入失败、并发访问、数据损坏、删除以及离线/在线切换。使用临时数据库或目录进行确定性测试。
适用场景
适用于 Flutter 应用需要处理本地存储选型、缓存策略、数据库迁移、离线同步与数据恢复等问题的设计与评审环节。
限制
资料未提供具体的包名、代码示例、安装命令、收费或价格信息，也未提供支持的平台清单与性能指标。