流式解析的核心是边接收边解析，将JSON视为事件流而非完整字符串，通过SAX风格监听结构变化，在节点闭合时即时触发回调处理，无需等待全部数据下载完成。
直接用流式解析思想，就能在数据还没下完时就开始读取和处理节点——关键不是等整个 JSON 到手，而是把传输过程变成“边收边拆”的流水线。
核心思路：把 JSON 当作数据流，而不是字符串
传统 JSON.parse() 要求输入完整、语法正确；而流式解析（如 Oboe.js 所采用的 SAX 风格）把 JSON 看成一系列事件：开始对象、遇到键名、读到值、结束数组……只要底层能识别出一个完整节点（比如一个 {"id": 123, "name": "Alice"}），就立刻触发回调，无需等待后续内容。
- 依赖底层解析器（如 Clarinet）按字节流喂入，实时报告结构变化
- HTTP 层需支持分块传输（Transfer-Encoding: chunked）或流式响应，浏览器中靠
XMLHttpRequest的progress事件或fetch + ReadableStream暴露原始字节流 - 路径匹配（如
'users.*'）是在解析过程中动态判断当前节点是否符合模式，不是先建树再查
实际操作：三步搭起可工作的流式读取链
以浏览器端加载 /api/users 为例：
-
发起流式请求：用
fetch获取响应体的ReadableStream，再用TextDecoder转为字符串流 -
接入解析器：将字符串流喂给 Clarinet 或 Oboe.js 内置解析器；注册
.node('users.*', callback)，每当一个完整用户对象解析完成，callback 就执行一次 - 即时消费结果：在 callback 中渲染列表项、存入 IndexedDB、或转发给图表库更新——这些动作与剩余数据下载并行发生
注意节点完整性：什么才算“可读取”
流式解析不是逐字符回调。它只在语义完整的节点上触发，比如：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
-
{"id": 1, "tags": ["a", "b"]}—— 整个对象闭合后才触发node回调 -
[{"id":1}, {"id":2}]—— 若监听'*'，两个对象会分别触发两次 - 但
{"id": 1, "profile": {这种未闭合的片段不会触发，解析器会缓存待续内容，直到结构完整
所以“边加载边读取”的前提是：服务端输出格式必须是标准 JSON（不能是 NDJSON 或行分隔 JSON），且目标节点本身是自包含的 JSON 值。
轻量替代方案：不引入 Oboe.js 也能做
如果只想快速验证流式能力，可用原生组合：
- 用
fetch().then(res => res.body.getReader())读取 Uint8Array - 用
TextDecoder累积字符串 - 配合简易状态机（如检测
{开始、计数嵌套层级、匹配}结束）提取完整对象 - 对每个提取出的字符串调用
JSON.parse()—— 此时它已是一个合法子树，安全可靠
这种方式绕过完整库，适合简单结构或定制化强的场景，也更易调试数据断点。
