解析超大JSON不卡死的关键是避免一次性解析，应采用流式或分块处理并主动让出主线程控制权；服务端切片、SSE/ReadableStream、Web Worker、分批+queueMicrotask写入IndexedDB及安全兜底措施共同构成完整方案。
解析超大 JSON 文件不卡死，关键不是“怎么 parse”，而是“不一次性 parse”。主线程被 JSON.parse() 长时间独占，用户就无法点击、滚动、响应任何操作。真正可行的路径是：绕开全量解析，用流式或分块方式把数据“喂”给 IndexedDB 或页面，中间主动让出控制权。
先判断是否真需要前端解析
很多场景下，所谓“超大 JSON”其实不该由浏览器承担解析压力：
- 服务端提前切片：把一个 50MB 的数组 JSON 拆成 100 个 500KB 的小文件（
data-0.json～data-99.json），前端逐个 fetch + 解析 + 写库，内存峰值可控 - 改用流式接口：后端提供 SSE 或 Fetch ReadableStream 接口，前端用
response.body.getReader()逐段读取，配合stream-json等库边流边提对象，不攒全量字符串 - 直接交由 Web Worker：把
JSON.parse()和后续处理逻辑移入 Worker，避免阻塞渲染线程；注意 Worker 间传数据要用postMessage+ 结构化克隆，别传大对象引用
必须在主线程处理？那就严格分批 + 主动让权
若受限于架构只能在主线程操作（比如离线 PWA 加载本地 JSON 文件），就必须手动拆解节奏：
- 先用
JSON.parse()解析——但仅限 ≤3–5MB 的原始字符串；超过这个量级，先用FileReader或fetch读取后做str.trim()和基础校验，再进 try/catch - 解析成功后立即切片：
const batches = chunkArray(allItems, 200)（每批 200 条是较稳妥起点） - 用
setTimeout(fn, 0)或queueMicrotask()分发每批写入任务，确保每批执行完都回到事件循环，释放主线程给 UI 响应 - 避免用
requestIdleCallback做主控——它不保证及时执行，在高负载下可能被跳过，适合作为“锦上添花”的进度反馈补充，而非主调度
写入 IndexedDB 时同步优化事务
分批只是第一步，写入慢照样卡：
立即学习“Java免费学习笔记（深入）”；
- 每个批次在一个
transaction内完成全部add()或put()，不要为每条数据开新事务 - 确保 objectStore 已预建好必要索引，否则写入时动态建索引会显著拖慢速度
- 主键尽量用客户端生成的稳定 ID（如
crypto.randomUUID()），避免依赖后端返回字段引发重复写失败 - 监听
transaction.oncomplete后再触发下一批，形成可控流水线，比单纯 setTimeout 更可靠
加一层安全兜底和可观测性
线上环境不能只靠“理论上不崩”：
- 封装
safeJsonParse(text)：先trim()，检查是否以<!或<html开头，再 try/catch，返回{ ok: boolean, data?, error? } - 记录每批耗时与错误数，用
performance.now()打点，异常时上报原始响应片段（非全量）用于定位 - 提供中断能力：加一个全局标志位
shouldAbort，每批开头检查，用户点击“取消导入”可立刻退出循环 - 进度反馈不只靠百分比——显示“已存 12,400 / 320,000 条”，并用
requestAnimationFrame更新 DOM，避免频繁重排
