超大 JSON 解析应搬入 Web Worker 并采用流式分块处理：通过 response.body.getReader() 边收边切，配合括号计数或换行分割；Worker 内用 stream-json 等事件驱动解析器提取关键字段，零拷贝传输轻量结构，结合 AbortController、IndexedDB 缓存与元数据优化提升性能与体验。
把超大 JSON 解析搬进 Web Worker，核心不是“换个地方跑”，而是**避开主线程阻塞 + 控制内存峰值 + 做增量处理**。直接 `JSON.parse()` 整个字符串丢进 Worker 依然会卡、会爆内存——得拆开揉碎了干。
分块流式读取，别等全部下载完
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 这类流式解析器：
- 监听
startObject开始缓存字段，key和value事件逐个提取关键字段 - 遇到
endObject立即判断是否匹配过滤条件（如status === 'active'） - 只把通过的轻量结构（比如
{id: 123, name: 'xxx'}）用postMessage回传，不传原始字符串或大对象
通信要轻，传输要快
主线程和 Worker 之间传数据，是性能第二瓶颈：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 避免传大 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 可据此预分配数组或调整分块大小
