IndexedDB 管理用户配置的核心是可维护、可同步、可回滚；需按业务分仓建模（ui_settings、api_config、sync_policy），合理设计主键与索引，采用先本地落库再后台同步策略，并通过平滑版本迁移保障兼容性。
直接用 IndexedDB 管理用户配置，核心不是“存进去”，而是让配置真正可维护、可同步、可回滚。它比 localStorage 更适合——不只是容量大，关键是结构清晰、支持事务和索引，能应对主题切换、API密钥更新、多设备偏好差异等真实场景。
配置数据建模：按业务逻辑分仓，不堆一个大对象
别把所有设置塞进一个叫 config 的 object store。按功能域拆分更可控：
- ui_settings：主题（dark/light/system）、字体大小、布局密度——高频读写，独立事务不影响其他配置
- api_config：后端地址、超时时间、认证 token（加密后存）、是否启用代理——需原子更新，避免部分字段失效
- sync_policy：自动同步开关、离线缓存时长、冲突处理策略（如“本地优先”或“服务端优先”）——常与网络状态联动
每个 store 设稳定主键，比如 ui_settings 用 id: "global"；api_config 可用 env: "prod" 作 keyPath，方便多环境隔离。
索引设计：让“查配置”变成毫秒级响应
用户配置查询往往带条件，光靠主键不够：
- 在
ui_settings上建by_theme索引，支持按 theme = "dark" 快速筛选（虽单条但便于扩展多主题） - 给
api_config建by_env唯一索引，确保 prod/staging/test 配置不冲突 - 在
sync_policy中加last_modified非唯一索引，方便同步队列按时间拉取待上传项
索引不是越多越好，只建实际被 store.index().get() 或 openCursor() 用到的路径。
写入与同步：先本地落库，再后台发请求
用户点“保存主题”时，流程必须是：
- 开启
readwrite事务，写入ui_settingsstore，标记synced: false - 立即触发 UI 更新（无需等待网络），保证操作即时反馈
- 监听
navigator.onLine或 fetch 失败，触发同步任务：批量收集synced: false记录，调 API 提交，成功后更新本地synced: true和server_id
失败时不丢数据，保留本地状态并加入重试队列（例如指数退避：1s → 3s → 9s）。
升级与兼容：版本迁移要平滑，不丢用户习惯
当新增一个配置项（如“夜间模式起止时间”），升级数据库版本时：
- 在
onupgradeneeded中检查旧版结构，若缺少字段，用默认值填充（如night_start: "22:00"） - 避免直接删字段；如废弃某配置，保留字段但加
deprecated: true标记，后续版本再清理 - 对关键配置（如 API 地址），升级前先读旧 store，迁移后验证新结构能否正确解析
这样用户从 v1 升到 v3，历史偏好依然完整可用，不会重置成默认值。
