这个一定要分页处理吧，而且要控制一下当前页面上数据的量，比如你同一时刻只能看到100条数据，那你就生成500个li，随着滚动条的位置变化，去更新这500个li。

可以延伸lazyLoad的思路，只渲染用户可以看见的数据。

数据量太大，一次塞入的DOM浏览器受不了，那么我们就换种思路，只展现用户可以看见的数据，用户看见哪儿，就只显示哪儿的数据。

1. 获取浏览器的页面高度，然后获取table的一行数据高度，求出页面中最大可以显示的行数。

2. 取出所有数据，先不渲染，计算设置table的高度，然后默认只渲染三屏的数据，这三屏的关系如下：

   +============+
   |            |
   |     A      |   ---  用户看不见
   |            |
   +============+
   |            |
   |     B      |   ---  用户可以看见
   |            |
   +============+
   |            |
   |     C      |   ---  用户看不见
   |            |
   +============+

3. 绑定scroll,计算用户当前正在浏览的table数据行。思路很简单：一直让用户都在浏览B。

   • 当用户滚动页面的时候，往上滚动到A，则把C移除DOM，，然后在A的上面填充数据，这样用户呈现给用户的结构又会变成上面画的结构。

   • 往下滚动到C，则把A移除DOM，然后在C的下面填充数据。

   • 之所以要三屏是为了让用户平滑滚动的时候，数据不会中断/空白，然后突然蹦出来。

4. 这样做有个问题，从页面顶部，直接拉滚动条到页面底部，页面填充速度会跟不上，所以会有卡顿和空白的情况，所以这里一定要做函数节流，当用户突然大幅度滚动的时候，先不显示数据，等用户停止滚动了之后，再渲染数据。

这个方案唯一的缺点是会在大幅度滚动的时候产生空白，但比如很大的数据渲染到DOM卡住浏览器，我觉得产品应该更能接受这种方案。

在手机上应用过这个方案，效果非常赞。

可以做分页处理

操作dom已经要记得缓存，$(#sourceList).length这种,你就要用个
var length = $(#sourceList).length 缓存起来，
不然你循环填数据，开销很大

一次性也看不完那么多数据，分段缓存到内存中，然后分页分别取出数据。