你打开Safari，加载一个几十MB的JSON文件——然后，一切就停了。

滚动失灵、点击无响应，甚至直接弹出“网页无响应”的提示框。

这不是网络慢。真相是JavaScript主线程被同步解析操作彻底锁死了。

卡死的根源在于JSON.parse()这个同步过程占用了主线程。几十MB的数据量，解析耗时可能达到秒级甚至更长。浏览器自然就“罢工”了。

怎么办？答案不是放弃JSON。而是把解析过程拆开、打散，或者干脆丢到后台去干。

确认是否为JSON.parse阻塞导致

别急着动手改代码。先确认问题到底出在哪。

打开Safari开发者工具（Cmd+Opt+I），切换到Console标签页。贴一段测试代码进去跑：

console.time("parse"); JSON.parse('{"a":1}'); console.timeEnd("parse")

如果耗时在0.1ms以内，说明浏览器解析基础JSON没问题。但如果耗时超过50ms，或者直接报错，问题就出在你实际处理的JSON字符串上。

接着，在Network面板中找到对应的接口。点击它，切换到Response选项卡，再点右上角的“Copy response”，把原始响应体复制出来。

关键点：一定要复制Response里的原始文本，别用Preview里美化后的版本——那东西不准。

用流式解析替代一次性JSON.parse

方法一：Safari原生支持的response.json()配合fetch中断检测

把原来那种老掉牙的写法：

fetch(url).then(r => r.text()).then(text => JSON.parse(text))

换成这个更现代的方式：

fetch(url).then(r => {
  if (!r.ok) throw new Error(r.status);
  return r.json(); // Safari 16.4+已支持，自动流式解析并分块释放内存
})

这种写法由WebKit底层接管解析流程。解析过程是流式的，内存分块释放，主线程不会被长时间占用。

前提条件：Safari版本必须≥16.4。低于这个版本，它会偷偷退化成同步解析，效果就等于没改。

方法二：手动分块解析超大JSON数组

这个方法有适用范围：JSON的根节点必须是数组。具体分三步走：

• 第一步：用response.body.getReader()读取流，逐段提取以[、]或,为边界的JSON片段。
• 第二步：每遇到一个合法的对象片段，就立即调用JSON.parse(chunk)，并马上处理——比如存入IndexedDB或者渲染首屏页面。
• 第三步：用AbortController监听用户是否要离开页面，如果离开就主动中断读取，避免后台继续吃CPU。

注意：这种方法开发成本较高，需要自己处理嵌套括号的匹配。仅推荐在数据结构固定、后端又能配合改造的场景下使用。如果根节点是对象，此方案无效。

强制降级为Web Worker解析

如果觉得上面的方案太折腾，还有一个更直接的办法：把解析任务丢到后台线程去干，别占用主线程。

新建一个json-parser.worker.js文件，内容如下：

self.onmessage = async ({ data }) => {
  try {
    const result = JSON.parse(data);
    self.postMessage({ type: 'success', payload: result });
  } catch (e) {
    self.postMessage({ type: 'error', message: e.message });
  }
};

然后在主页面中这样调用：

const worker = new Worker('json-parser.worker.js');
worker.postMessage(largeJsonString);
worker.onmessage = ({ data }) => {
  if (data.type === 'success') render(data.payload);
};

这里有一个硬性条件：largeJsonString必须是字符串类型，不能是Blob或ArrayBuffer。如果原始数据是从fetch获取的，需要先调用response.text()拿到字符串，再传给Worker。

这一步完成后，页面就能恢复响应了——用户可以正常滚动、点击，毫无压力。

解析结果会通过postMessage异步返回，主线程再也不会被锁死。

《夸克》非常好用的免费AI浏览器

下载APP查看