超大 JSON 解析应搬入 Web Worker 并采用流式分块处理:通过 response.body.getReader() 边收边切,配合括号计数或换行分割;Worker 内用 stream-json 等事件驱动解析器提取关键字段,零拷贝传输轻量结构,结合 AbortController、IndexedDB 缓存与元数据优化提升性能与体验。

分块流式读取,别等全部下载完
fetch 拿到 response 后,别用 res.json() 或 res.text()——那会把整个文件加载进内存再传给 Worker。改用 response.body.getReader() 边收边切:
- 如果是 JSONL(每行一个 JSON 对象),按换行符
\n切分,每拿到一行就发给 Worker 解析一次 - 如果是标准 JSON(单一大对象),用括号计数法识别
{和}的嵌套层级,拼出完整对象后再送入 Worker - 配合
AbortController,用户取消时立刻中断读取,不浪费带宽和 CPU
Worker 内用事件驱动解析器,不建全量对象
在 Worker 里也别用 JSON.parse() ——它必须等完整字符串才能开始,且生成完整 JS 对象树,内存占用翻倍。换成 stream-json 或 jsonparse 这类流式解析器:
使用约定式提交(Conventional Commits)生成标准化的 Git 提交信息。适用于以下场景: (1) 暂存更改时需要提交信息; (2) 审查 diff 时希望获得结构化摘要; (3) 编写 PR 描述或变更日志(changelog)条目; (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff,并生成按类型(type)划分范围的提交信息。
- 监听
startObject开始缓存字段,key和value事件逐个提取关键字段 - 遇到
endObject立即判断是否匹配过滤条件(如status === 'active') - 只把通过的轻量结构(比如
{id: 123, name: 'xxx'})用postMessage回传,不传原始字符串或大对象
通信要轻,传输要快
主线程和 Worker 之间传数据,是性能第二瓶颈:
- 避免传大 JSON 字符串:先用
TextEncoder.encode()转成Uint8Array,再用postMessage(data, [data.buffer])实现零拷贝 - 如果必须传对象,用
structuredClone()替代JSON.stringify() + JSON.parse(),支持Date、Map等原生类型,更快更安全 - 别传函数、DOM 节点、循环引用对象——Worker 会静默失败或报错
加缓存和取消机制,体验更稳
用户反复切换筛选条件或刷新页面时,别让 Worker 白干:
- Worker 内部监听主线程发来的
{ type: 'abort' }消息,收到后立即退出解析循环 - 首次解析成功的结果,存进
IndexedDB(用put()存ArrayBuffer或结构化克隆),下次加载先查缓存,命中就跳过解析 - 服务端若支持,提前返回元数据(总条数、字段类型),Worker 可据此预分配数组或调整分块大小

















