今天给大家分享一篇校招比较高频的面试题目（虽然实际场景遇到的概率不大）：

后端一次性返回十万条数据给前端，前端这边怎么处理？

我们大概可以按照下面这些方法来尝试，看看实际效果。

十万条数据直接插入DOM

简单粗暴的方法，啥都不想，以前都是直接把后端返回的列表数据插入DOM的，这次也这么搞。其实先尝试简单粗暴的方法，我认为是没问题的，不能因为网上说直接插入DOM会导致页面卡顿，就不去尝试了，最好还是能自己去实际实验一下，毕竟实践是检验真理的惟一标准。

除非DOM结构非常简单，其他情况下，一般都会导致页面卡顿，至少滚动过程白屏。显然，这样粗暴的一次性插入全部数据不太靠谱。

前端分页渲染数据

前端拿到十万条数据之后，先暂存起来，根据当前要展示的页码，要么只渲染对应页码的数据（使用 table 分页展示场景），要么增量的渲染新一页的数据（无限滚动瀑布流场景）。

如果业务场景可以使用 table 分页渲染数据，其实是可以比较好的解决这个问题。但是 table 分页展示，通常是中后台的系统里，在C端，经常是瀑布流的场景。

针对C端瀑布流场景，我们需要在前端根据业务情况，设定每一页的数据大小，当滚动到底部时，渲染新的一页数据并 追加 到DOM里。但是这种方案并没有解决用户一直翻页，最终DOM里仍然会插入大量的元素，导致页面越来越卡顿。这种情况，就需要用到下面的方案了。

虚拟列表

根据前面的分析可以知道，我们目前要解决的主要问题，是 DOM里元素数量过多 的问题，因此，我们要想一种方案，能够保证不管要渲染多少数据，DOM里实际渲染的数量上限是一定的。

虚拟列表（长列表、table、 select） 等，就是这样一种技术。虚拟列表只对 可视区域内 的数据进行渲染，在可视区域外的数据，不会实际渲染，因此保证了不管总的列表项再多，实际DOM内也只会渲染一上部分元素，彻底解决 渲染层面 的大数据量卡顿问题。

多线程？

在上面讨论中，主要解决的是 DOM渲染 导致的卡顿，除了这种情况，还有可能我们需要在JS里对这十万条数据做一些比较复杂的计算，之后才能用于渲染。

如果我们直接遍历十万条数据，进行计算，那还会遇上 JS执行导致的卡顿问题。因为在JS执行过程中，浏览器不能处理渲染工作，页面也会卡住。要解决大数据量下JS计算耗时过长，或者JS计算过于复杂的问题，有如下方案：

1. 如果是以前，通常我们可以用 setTimeout 这样的方式来 模拟多线程 ，其实也是对数据进行分片（分页）处理的思想，每次处理一小部分，然后把JS执行停一下，让UI渲染进程可以去渲染页面、响应用户交互行为
2. 后来，浏览器出了 Web Worker 这样的原生的 多线程 解决方案，我们可以把数据提交给单独的一个 Worker ，把计算任务都放在这个独立的 Worker 上面，等计算完成之后，再把 分页 的数据传给主线程，主线程只负责渲染

题目点评

这类问题的考察点其实比较清楚，一是大量DOM渲染上的卡顿问题，二是JS执行复杂计算导致的卡顿。总体思路都是一样的，分页+虚拟列表+多线程 。

1. DOM渲染上，采用分页或虚拟列表，大大减少实际的DOM数量
2. JS执行时间过长方面，传统的 setTimeout 方案也算是一种分页，把数据分片处理；而新的 Web Worker 是针对JavaScript单线程问题，提供的单独的纯计算线程，解决JavaScript执行导致的页面卡顿