IndexedDB 通过预处理结构化数据、异步解析和按需水合解决大 JSON 解析阻塞问题：拆解字段、分批写入、Web Worker 解析 raw 数据、索引查询替代 JS 过滤，并支持硬件降级与校验兜底。
直接用 JSON.parse() 解析大型 JSON 字符串会同步阻塞主线程，尤其在几十 MB 级别时，页面完全卡死。IndexedDB 本身不解析 JSON，但它能帮你把“解析”这个动作从主线程中移出——关键不是存 JSON，而是**提前结构化、异步写入、按需水合**。
先拆解再存储：拒绝 raw JSON blob
不要把整个 JSON 字符串或深度嵌套对象直接 put() 进 objectStore。那样只是把解析压力推迟到读取时（你仍得 JSON.parse()），且无法建索引、无法定向查询。
- 在数据进入 IndexedDB 前，用 Web Worker 或
setTimeout微任务做一次轻量级预处理：提取高频查询字段（如id、type、updated_at）、拍平嵌套路径（user.profile.city → user_profile_city）、剔除非必要属性 - 保留原始 JSON 的压缩副本（如用
JSON.stringify()后 gzip 压缩为Uint8Array）存入单独字段（例如raw_data），但不用于筛选 - 主对象结构只含可索引字段 + 原始数据的哈希或长度等元信息，确保单条记录体积可控（建议 ≤ 10KB）
水合时机交给业务逻辑，而非首次加载
“水合”不是一上来就把全部原始数据解析成 JS 对象，而是按需、分片、延迟执行：
- 列表页只读取结构化字段（如
title、status、preview），用索引快速游标遍历，毫秒级返回 - 用户点击某条目后，再通过主键
get()拿到对应记录，取出raw_data字段，在 Web Worker 中调用JSON.parse()，完成后 postMessage 回主线程 - 对搜索/筛选场景，永远基于结构化字段查（如
index.get(IDBKeyRange.only("active"))），绝不遍历 raw 字段再 JS 过滤
用事务和分批控制解析负载
大批量导入原始 JSON 时，避免单次事务塞入上万条：
- 将原始 JSON 数组按 200–500 条分块，每块在一个独立
readwrite事务中写入 - 每批写完后用
setTimeout(() => {}, 0)让出主线程，防止连续 JS 执行导致页面无响应 - 若原始数据含二进制内容（如 base64 图片），直接存为
Blob或ArrayBuffer，IndexedDB 原生支持，无需 JSON 编解码
兜底与渐进式降级
不是所有设备都适合跑大 JSON 水合：
- 检查
navigator.hardwareConcurrency，低于 2 核时默认跳过 Web Worker 解析，改用主线程懒加载 + 骨架屏 - 首次加载失败（如解析超时、内存不足），回退到 localStorage 中缓存的简化版结构化数据（不含 raw 字段）
- 给
raw_data字段加 CRC32 校验，读取后比对，避免损坏 JSON 导致JSON.parse()报错中断流程
