indexeddb 管理大型应用本地数据的核心是高效读写、精准查询与内存可控：需按业务域拆分 object store、存原生对象而非字符串、为高频字段建索引、分批事务+ttl清理、加密敏感字段、启动校验与懒加载。
用 IndexedDB 管理大型应用的本地配置与缓存数据，核心不是“能不能存”，而是“怎么让读得快、写得稳、查得准、不爆内存”。它不是 localStorage 的放大版，而是一个需要建模、索引和生命周期管理的轻量级客户端数据库。
按业务域拆分 object store，避免单表臃肿
别把所有配置和缓存塞进一个 store。比如用户偏好、API 路由模板、UI 主题、离线任务队列，应各自独立建 store：
-
profiles：存用户个性化设置，主键用
userId，索引加lastModified -
api_configs：存后端接口参数模板，主键可用
endpointHash（如sha256("/v1/users?role=admin")），索引建在service和version上 -
ui_themes：存主题 JSON 对象，主键用
themeId，索引加isDefault方便快速取默认项 -
offline_queues：存待同步的操作日志，主键用自增
autoIncrement: true，索引建在status和createdAt上便于批量清理
这样既降低单 store 容量压力（建议单 store 控制在 20MB 内），也方便按模块启用/清空缓存，不影响其他数据。
存对象，不存字符串；建索引，不靠遍历
大型 JSON 配置文件（比如含嵌套 schema、条件规则、预设参数）必须以原生 JS 对象形式传入 put()，而非 JSON.stringify() 后存储：
- ✅ 正确：
store.put({ id: "cfg-ai-gen", model: "flux-dev", maxSteps: 50, updatedAt: Date.now() }) - ❌ 错误：
store.put(JSON.stringify(cfg), "cfg-ai-gen")—— 索引失效，字段无法被查询，游标无法定位
高频查询字段必须显式建索引：
- 按分类查配置？建
createIndex("category", "category") - 按更新时间范围拉最新 10 条？建
createIndex("updatedAt", "updatedAt")，再用IDBKeyRange.bound(start, end) - 查是否启用某开关？建
createIndex("isEnabled", "isEnabled")，支持布尔值精确匹配
没索引的 getAll() 在 5000 条以上就可能卡死 DevTools 面板——这不是代码问题，是浏览器渲染器扛不住全量扫描。
分批事务 + TTL 清理，防止无限膨胀
配置和缓存数据不是“写一次永留存”。需主动控制生命周期：
- 插入时带上
expiresAt字段（如Date.now() + 30 * 24 * 60 * 60 * 1000），配合定时任务用游标扫描过期项并delete() - 批量写入超过百条时，切分为每批 200–500 条，每次
transaction.complete后再启下一批，避免长时间锁库 - 监听
navigator.storage.estimate()，当使用率 >75% 时触发分级清理：先删offline_queues中 status 为 "sent" 的项，再删api_configs中updatedAt超过 90 天的记录
敏感字段（如 API token、加密密钥）绝不明文存入；必须存时，用 Web Crypto API 加密后再写入。
启动时校验 + 按需加载，保障离线一致性
大型应用常需离线可用，但分片或索引出错会导致数据不可用：
- 每个 store 写完后，在
manifeststore 中记录该配置块的条目数、CRC32 值和最后更新时间 - 应用冷启动时比对
manifest与实际store.count()，不一致则自动重建索引或重载缺失块 - 长列表展示配置项时，结合
IntersectionObserver懒加载，只预取可视区域前后 1–2 页的数据，用游标continuePrimaryKey()分页拉取，避免一次性 load 全量
不复杂但容易忽略。
