流式解析json的核心目标是边接收、边处理、边丢弃，避免全量加载导致内存暴涨和主线程阻塞；它通过事件驱动（如sax）按需提取字段，跳过冗余结构，并配合web worker和服务端分页/裁剪实现高效大数据渲染。
大数据量表格渲染前，流式解析 JSON 的核心目标是：不等整个响应体下载完、不把全部数据一次性加载进内存、不阻塞主线程。它把“解析”这个动作拆解成小块，边接收、边处理、边丢弃无用部分，尤其适合处理几十MB甚至上百MB的 JSON 数据。
为什么不能直接用 JSON.parse()
JSON.parse() 是同步全量解析。100MB 的 JSON 字符串，解析后对象可能占 500MB~1GB 内存，同时主线程被锁死数秒——页面卡死、交互冻结、浏览器可能弹出“无响应”警告。这不是优化问题，而是架构级风险。
用流式解析器替代全量解析
主流方案是使用支持 SAX（事件驱动）或类似机制的流式 JSON 解析库，它们不构建完整 AST，而是触发回调通知你“现在遇到一个对象开始”“现在读到一个字段名”“现在拿到一个字符串值”。你只在需要时保存关键字段，跳过无关结构。
- 前端推荐库：jsonstream（Node.js 环境）、clarinet（轻量、兼容性好）、oboe.js（专为浏览器设计，支持 HTTP 流、自动重连、可中断）
- Node.js 推荐库：stream-json（模块化、内存极省）、JSONStream（老牌稳定）、fast-json-parse-stream（高性能）
- 关键原则：选择能按需提取字段、支持 pause/resume、允许 early exit 的库，避免封装过重的“类框架”解析器
只提取表格所需字段，跳过冗余结构
表格通常只需要扁平字段（如 id、name、status），而原始 JSON 可能是嵌套对象数组、带元信息、含大量描述字段。流式解析时，你只需监听特定路径，其余层级直接忽略。
- 例如原始结构：
{"meta":{"total":100000},"data":[{"id":1,"user":{"name":"张三","profile":{"age":28}}}]} - 你只需监听
$.data.*.id和$.data.*.user.name路径，其他字段（如 profile.age、meta.total）不进入内存 - oboe.js 示例：
oboe(url).node('data.*', row => { tableRows.push({id: row.id, name: row.user?.name}); })
配合 Web Worker 避免主线程阻塞
即使用了流式解析，如果在主线程做字段提取、格式转换、预处理（如日期格式化、状态映射），仍可能造成卡顿。把整个流式解析 + 数据清洗逻辑移到 Web Worker 中执行。
- 主线程只负责发起 fetch 请求，将 Response.body.getReader() 的流传递给 Worker
- Worker 用 stream-json 或自定义解析器逐 chunk 处理，每解析出 N 条有效记录，就 postMessage 给主线程
- 主线程收到批次数据后，用 requestIdleCallback 或 setTimeout 分批渲染，保障 UI 响应
服务端协同：优先启用分页或列裁剪
流式解析是客户端兜底手段，最优解永远是源头减负：
- 要求后端提供分页接口（
?page=1&size=50），前端按需加载，彻底规避大 JSON - 支持字段筛选（
?fields=id,name,status），服务端只序列化必要字段，体积直降 40%~70% - 若必须返回全量，建议后端改用列式 JSON（
{"columns":["id","name"],"rows":[[1,"张三"],[2,"李四"]]}），解析效率比对象数组高 3~5 倍
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
