虚拟列表是在滚动时计算出要渲染的元素在数组中的索引范围，普通的定高、不定高的计算量不大，很流畅，但是不定高的瀑布流，还伴随着图片加载的话，计算量就很大了，写过个 demo ，https://list.qcqx.cn/#/list/virtualwaterfall
在桌面 UI 时代，有一个东西叫做 onDraw (clipRect)：UI 框架告诉你，现在你这个控件需要显示 (x0,y0) -> (x1,y1) 区域的东西，你自己画吧。 所以你根本不需要构造一堆 DOM 元素。列表在你的内存里面仅仅是数据，比如 List[{name: Steven, age: 13, ...}]，然后你自己先把每个列表项渲染出来的坐标范围给计算出来存着，然后根据 UI 的需求把显示出来的对象画出来就可以了。 而且如果你遍历一遍你的列表找 (x0,y0) -> (x1,y1) 范围内的元素慢（这是 O(n) 的操作），你可以上数据结构，比如线段树，然后你就 O(log n) 了。 用上这套优化，百万个元素也不在话下。毕竟内存里面放一百万个对象才多少，也就几百兆么（注意 1 兆 = 一百万字节）。 ---- 题外话，所以很多前端不理解 “干嘛老考数据结构和算法”，那是因为没遇上需求。。。
另外吐槽一句，上古时代 onDraw 要写的东西太多了以至于是大神才能玩的。 后来各大 UI 框架都有了它们自己的绘图的框架，降低了这套东西的难度。我学得少，只知道一个 Qt 的 GraphicsView 干这事，还有 JS 可能有一些 Canvas 的库干这些活。其他就不知道了。
