能，但需结构化存储并建索引：提取关键字段（含嵌套字段拍平）、显式创建单/复合索引，用IDBKeyRange定向查询；避免全量遍历、大事务写入及undefined/Nan索引值。
IndexedDB 能否高效存取大量 JSON 数据？
能，但必须放弃“把整个 JSON 当 blob 存”的偷懒做法。IndexedDB 本身不解析 JSON，也不支持 SQL 式 WHERE 查询；直接 put() 一个大对象，后续想按 user.status === "active" 或 order.total > 1000 筛选，只能遍历游标 + JS 过滤——数据量一过万条，页面就卡死。
真正可行的路径是：**在写入前结构化提取关键字段，建索引；查询时用 IDBKeyRange 定向定位，而非全表扫描**。
- 避免把整个 JSON 当
value存，而要拆出高频查询字段（如status、created_at、category）作为对象属性 - 每个需要筛选的字段，都得在
createIndex()时显式声明，且注意复合索引顺序影响查询能力 - 超过 5 万条记录时，建议分库或按时间分片（如每季度一个 objectStore），否则打开事务就延迟明显
如何为 JSON 中嵌套字段建索引？
IndexedDB 不支持点号路径索引（例如不能直接对 user.profile.city 建索引）。必须在存入前把嵌套值“拍平”到顶层属性。
比如原始 JSON 是：
{ "id": 1, "user": { "name": "Alice", "profile": { "city": "Shanghai", "age": 32 } } }
应转为：
{ "id": 1, "user_name": "Alice", "user_profile_city": "Shanghai", "user_profile_age": 32 }
- 索引只能基于顶层字段创建：
objectStore.createIndex("by-city", "user_profile_city") - 若需按
city+age组合查，建复合索引：createIndex("by-city-age", ["user_profile_city", "user_profile_age"])，注意数组顺序决定可查询模式（["city", "age"]支持city === "X"或city === "X" && age > 30，但不支持仅age > 30） - 别在
onupgradeneeded外调用createIndex()，否则报错InvalidStateError
复杂条件筛选怎么写才不卡顿？
所谓“复杂条件”，本质是多个索引字段的交集或范围组合。IndexedDB 没有 OR、NOT、模糊匹配（LIKE）原生支持，得靠策略折中：
- AND 条件优先走复合索引：
IDBKeyRange.bound(["A", 25], ["A", 35])查city === "A" && age ∈ [25,35] - OR 条件必须拆成多次
openCursor()请求，用 Set 合并 key，再批量get()——别在游标里反复get()，会触发 N 次 IO - 想实现“包含某字符串”？提前存 n-gram 或关键词数组，建多值索引：
createIndex("by-tags", "tags", { multiEntry: true })，然后用IDBKeyRange.only("react") - 排序必须依赖索引顺序：想按
created_at DESC查，索引就得建为createIndex("by-date-desc", "created_at", { unique: false })，查询时加direction: "prev"
大量写入时如何避免 QuotaExceededError？
Chrome 对单个 origin 的 IndexedDB 有隐式配额（通常几百 MB），但更常见的是因单次事务过大被中断，报 QuotaExceededError 或 UnknownError。
- 别一次性
put()10 万条：拆成每批 500–1000 条，用递归事务控制节奏 - 写入前确认是否已存在：用
get()检查 key，避免重复写入膨胀体积 - 定期清理：用
delete()配合游标删过期数据，比清空整个 objectStore 更可控 - 监听
storage事件没用——IndexedDB 不触发它；真要监控容量，只能靠估算（每条记录 ≈ JSON.stringify() 字节数 × 1.3）
最易被忽略的一点：所有索引字段值都不能是 undefined 或 NaN，否则该记录无法被任何基于该索引的查询命中，且不会报错——静默失效，排查极难。
