IndexedDB 存储超大配置数据需结构化拆分、按查询路径建复合索引、分片存储及增量更新。拍平字段、剔除非关键属性、校验索引值，分批事务写入、索引存在性检查、localStorage 降级兜底。
用 IndexedDB 存储超大容量的离线业务配置 JSON 数据，关键不是“能不能存”，而是“怎么结构化、怎么索引、怎么读得快”。直接 put() 一整个 JSON 字符串或嵌套对象，后续查起来就只能遍历 + JS 过滤——数据量过 5 万条，页面基本卡死。
把 JSON 拆成可索引的字段结构
业务配置数据通常有固定 schema（比如 feature_flag、region_rules、version、enabled、updated_at），别把它当黑盒 blob。写入前必须做两件事：
- 把深层嵌套字段拍平到顶层，例如
config.rules.payment.max_amount→ 提取为payment_max_amount: 5000 - 只保留高频查询字段作为 objectStore 的属性，其余非关键字段可压缩进一个
metadata字段（仍为 JSON 字符串，但不用于筛选） - 确保所有待索引字段值不为
undefined或NaN，否则索引会失效或报错
按业务维度建索引，而非全字段覆盖
索引不是越多越好，而是要匹配真实查询路径。比如配置常按以下方式查：
- 按环境 + 功能名：建复合索引
by-env-feature，字段顺序为["env", "feature"] - 按生效时间范围：用
IDBKeyRange.bound(start, end)查valid_from和valid_until - 按版本号降序获取最新一条：索引
version并设{ unique: false }，查询时用openCursor(null, 'prev')
注意：复合索引 ["a", "b"] 支持 a === X 或 a === X && b > Y，但不支持仅 b > Y；单字段索引无法替代复合索引的组合能力。
分片存储 + 增量更新机制
单个 objectStore 超过 10 万条记录后，打开事务和游标延迟明显上升。建议按业务逻辑分片：
- 按模块拆：如
feature_configs、ui_themes、locale_messages各自独立 objectStore - 按时间/版本拆：例如每季度新建一个 store（
configs_2026_q1），旧数据归档只读，新数据写入当前 store - 同步时走增量：服务端返回
{ added: [...], updated: [...], removed: [...] }，前端用addAll()、put()、delete()分批操作，避免全量重刷
读写优化与容错细节
大配置数据对稳定性要求高，需控制事务粒度和错误兜底：
- 写入时拆成 500 条/批的事务，避免单事务过大触发浏览器限制或中断失败
- 读取前先检查索引是否存在，用
objectStore.indexNames.contains('xxx')防止运行时报NotFoundError - 首次加载失败时，回退到 localStorage 缓存的上一版 JSON（仅作降级，不用于查询）
- 用
structuredClone()（现代浏览器支持）深拷贝读出的数据，避免意外修改缓存对象影响后续逻辑
