有这样一个场景：从后端 API 请求回来一个巨大的 JSON 文件，可能是几十上百兆的报表数据、地理信息或用户列表。当我们尝试用 JSON.parse() 解析它，然后将其渲染到页面时，整个浏览器标签页突然“冻结”，失去了响应，甚至弹出了“页面无响应”的警告？
这是前端开发中一个典型且棘手的性能瓶颈。用户交互的卡顿是体验的“头号杀手”。
为什么庞大的 JSON 会让页面卡顿？
要解决问题，必先理解其根源。问题的核心在于 JavaScript 的单线程模型和浏览器的渲染机制。
- 阻塞主线程的解析：
JSON.parse()是一个同步的、计算密集型的操作。当它处理一个巨大的 JSON 字符串时，会长时间占用 JavaScript 主线程。在此期间，主线程无法处理任何其他任务，包括用户的点击、滚动事件，也无法执行任何动画或 UI 更新。这就是页面“假死”的直接原因。 - 内存的瞬间飙升：将巨大的 JSON 字符串解析成 JavaScript 对象，会消耗大量内存。如果数据量过大，可能会导致浏览器内存溢出，页面崩溃。
- 耗时的 DOM 操作：即使数据成功解析，将数万甚至数十万条数据一次性渲染成 DOM 节点，也是一场灾难。每一次 DOM 的创建、插入都会引发浏览器的重排（Reflow）和重绘（Repaint） ，这个过程极其耗费性能，同样会阻塞主线程。
想象一下，主线程就像一条单行道。JSON.parse() 和海量 DOM 操作就像两辆超长超重的卡车，它们一旦上路，就会堵死整条道路，所有其他车辆（用户交互）都只能等待。
核心解决策略：组合拳出击
解决这个问题没有单一的“银弹”，而是需要根据场景，打出一套漂亮的组合拳。策略主要分为三大方向：数据源优化、数据处理优化和数据渲染优化。
策略一：从源头解决 —— 与后端协作
最有效的优化往往发生在问题的最上游。
1. 数据分页（Pagination）
这是最经典、最有效的方案。一次只请求当前视图需要的数据（例如，每页 20 条）。后端提供分页接口，前端通过页码或滚动加载（Infinite Scrolling）来请求后续数据。
优点：
- 请求和响应的数据量极小，网络开销低。
- 解析和渲染的负担被分散到每次请求中。
- 实现简单，是绝大多数列表场景的首选。
2. 数据筛选与裁剪
与后端约定，只请求必要的字段。如果一个用户对象有 50 个字段，但列表只显示 3 个（头像、昵称、ID），那么就只让后端返回这 3 个。这可以极大地减小 JSON 的体积。
GraphQL 在这方面表现出色，它允许前端精确声明需要哪些数据，从根本上杜绝了数据冗余。
策略二：优化数据处理 —— 解放主线程
如果无法在后端进行优化，必须一次性接收所有数据，那么优化的重心就转移到了前端的数据处理阶段。
1. 使用 Web Worker 进行解析
Web Worker 是浏览器提供的“多线程”能力。我们可以将耗时的 JSON.parse() 任务放到一个单独的 Worker 线程中去执行，从而解放主线程。
主线程代码 (main.js):
Worker 线程代码 (json-parser.worker.js):
通过这种方式，即使用户在数据解析期间进行滚动或点击，页面也能立刻响应。
2. 流式解析（Streaming Parsing）
对于超大 JSON，我们可以使用 Fetch API 的 ReadableStream 来流式处理响应体，而不是等待整个文件下载完成。这意味着数据可以一块一块地被处理。
以上内容转载自 story 的《面对后端传来的海量 JSON 数据，如何优雅处理并保持页面流畅？》
