JSON.parse()在大型数据上卡顿因全量解析阻塞主线程并触发大量GC；预分析通过reviver裁剪字段或JSONStream流式解析降低内存占用，避免隐式全量解构。
为什么直接 JSON.parse() 在大型数据上会卡顿
因为浏览器的 JSON.parse() 是全量解析：它必须读完全部字符串、构建完整 AST、再生成嵌套对象。对 10MB+ 的 JSON，这不仅耗内存，还会阻塞主线程——尤其在初始化阶段触发大量 GC，实际表现就是页面“假死”几秒。
预分析的核心不是跳过解析，而是提前知道「哪些字段真正需要立刻访问」，从而避免构造整棵树。典型场景是：你只关心 data.items[0].title 和 data.meta.total，但原始 JSON 里还有 50 个未用字段和 2 万条冗余记录。
用 JSON.parse() 的 reviver 参数做轻量级字段裁剪
reviver 能在解析过程中逐层拦截键值对，比全量解析后再 delete 更省内存和时间。关键点在于：它不改变解析流程，只是提供一个“钩子”来丢弃不需要的分支。
- 只保留顶层
meta和items字段，忽略debugInfo、rawLog等调试字段 - 对
items数组，只保留前 100 项（或按需过滤），其余直接返回undefined让解析器跳过 - 避免在 reviver 里做深拷贝或格式转换——那会抵消掉所有性能收益
const result = JSON.parse(jsonString, (key, value) => {
if (key === 'debugInfo' || key === 'rawLog') return undefined;
if (key === 'items' && Array.isArray(value)) {
return value.slice(0, 100); // 只取前 100 条
}
return value;
});
对超大数组用流式解析 + JSONStream 替代全量加载
当 JSON 是标准格式且结构固定（比如 {"data": [{"id":1}, {"id":2}, ...]}），JSONStream 可以边读边解析，把内存占用从 O(N) 降到 O(1)。它不依赖完整字符串，而是监听特定路径的匹配事件。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 只订阅
data.*.id和data.*.title，其他字段完全不进 JS 堆 - 注意：它要求 JSON 文件是严格换行分隔或符合 JSONPath 规则，不支持任意嵌套混排
- Node.js 环境可直接用；浏览器需搭配
fetch().body+ReadableStream和JSONStream的 ESM 版本
错误示例：JSONStream.parse('data.*') 会把整个对象载入内存；正确写法是 JSONStream.parse('data.*.id') 或 JSONStream.parse('data.*.title')。
预分析后仍要防「隐式全量解构」
很多人裁剪完 JSON，却在后续代码里写 const { items, meta, debugInfo } = result——即使 debugInfo 是 undefined，解构赋值仍会遍历所有 ownKeys，对 10 万字段的对象，这本身就会卡住。
- 显式访问字段：
result.meta?.total、result.items?.[0]?.title - 避免
Object.keys(result)、for...in、JSON.stringify(result)这类全量操作 - 如果必须遍历，先用
Object.getOwnPropertyNames()检查字段数是否异常（比如 > 100 就报警）
真正影响初始化速度的，往往不是解析那一瞬间，而是解析后第一轮访问时的意外行为。预分析只是把问题暴露得更早，而不是自动解决所有隐患。
