大 JSON 文件处理与性能优化

一、先定位根因：主线程阻塞与 DOM 爆炸

大 JSON 卡顿几乎都来自下面两点，认清它们才能对症下药：

• 主线程阻塞。浏览器 JS 是单线程，若在主线程里直接 JSON.parse 一份几十 MB 的文本并做语法高亮，解析期间滚动、输入、点击全部排队，界面直接「假死」。
• DOM 节点爆炸。把整棵树一次性渲染成元素，百万节点就是百万个 DOM 节点。即使解析很快，仅创建和布局这些节点就足以让页面卡顿、内存暴涨。

对应的两条解法是： 把计算挪出主线程，以及 只渲染看得见的部分。

二、Web Worker：把解析挪出主线程

Web Worker 是浏览器提供的后台线程，与主线程共享内存但不阻塞它。把完整的 JSON.parse、校验、格式化、树构建、搜索都放进 Worker 后，主线程只负责渲染与响应交互。 效果很直接：解析进行中界面依然显示「解析中」并可滚动，不再出现无响应的白屏。

本站的格式化、校验、压缩、树视图、查询等能力都遵循这一模式：重活在 Worker，主线程只画界面。所以同样一份 10MB 文件，不会先卡上好几秒，界面始终可交互。

三、窗口化渲染：DOM 只保留可视区

光有 Worker 还不够。如果主线程仍要一次性渲染全部节点，DOM 爆炸照样会卡。树视图因此采用 会话化窗口协议：

• Worker 侧解析并持有完整值树，同时算出一份「可见行」模型。
• 主线程按视口分页拉取附近的行（每页 100 行），滚出视口的行自动回收。
• 因此 DOM 节点数与内存占用与文件总大小无关。

换来的是滚动全程顺滑：12 万节点全部展开后，滚动、搜索跳转依旧流畅，内存不随文件膨胀。快速滚动时个别行可能短暂空白，那是按需拉取尚未补齐，停手即恢复。

四、超过 5MB：文本区切换只读分片

代码编辑器会对整份文档做增量语法解析，超大文档、尤其是单行压缩 JSON 下，输入与高亮会明显掉帧。 所以文本区超过 5MB 时自动切换为 只读分片视图：固定行高虚拟滚动 + 行号 + JSON 语法着色，并保留错误行定位；超长单行会截断显示并提示先格式化。

需要改值时不必回到文本编辑：用 树视图 的行内编辑按路径改叶子值即可，改完文本区同步刷新。若必须先编辑整份文本，可先压缩或裁剪无关字段，把体积降到 5MB 以内。

五、按需分包：别让首屏背大依赖

性能不只在运行时，也在加载时。本站把重依赖都做成按需加载：jq 引擎（WebAssembly，约 0.9MB）只在第一次发起 jq 查询时才动态下载；各语言实体类生成器、格式互转等能力也各自独立分片，用哪种才下载哪种。

对使用者的意义是：打开工具页不必等所有引擎就绪，核心的格式化、树浏览即时可用。只有真正用到查询 / 生成时，才付出对应资源的加载成本。

六、处理大文件的实操清单

• 先格式化，再浏览。单行压缩的超大 JSON 不适合直接读；先到 JSON 格式化 缩进对齐，树浏览与分片视图都会更顺畅。
• 用搜索代替全展开。大文件里「全部展开」会产生海量行；输入键名或值片段搜索，命中会自动展开祖先链并跳转，一步到位。
• 丢给表达式做筛选。只想按路径取子集时，用 jq 或 JSONPath 在 Worker 里一次算完，比人肉逐层翻树快得多。
• 注意整数精度。含雪花 ID 等超 2^53-1 的整数时，开启大整数（BigInt）模式，避免末位被改写。
• 确认隐私边界。解析、搜索、改写全在本机 Worker 完成，无后端与数据库，本地文件只经浏览器 File API 在内存读取，可在 F12 Network 面板自证零上报。