Chuckle

@iapplebear 不过这毕竟只是个 demo ，我感觉嵌套起来用应该会有些问题，性能上或者是布局计算上

@iapplebear 每个列表元素的 dom 结构可以通过插槽自定义，你可以通过二维数组实现这个功能，外面是一层不定高虚拟列表，用于区分每一天，然后每个元素里面又是一个不定高虚拟瀑布流来展示该天的所有照片，通过这样嵌套两层虚拟列表，应该可以满足你的需求。

@DOLLOR 主要还是小红书、抖音这种无限往下滑动的场景，快速找到并滚动到最后一次看的视频也是个算法题（

@crz 原生的滚动条确实应该隐藏掉，要的话应该再写个虚拟滚动条，小红书也是把滚动条隐藏了，demo 不直接展示 2000 条，也是因为实时计算是找最小高度的列，以其为基准，所以肯定是少于 2000 条的，确保体验，不然有些列长度太短了，留白难看，因为是不定高，所以每次加入元素只能找最短列，但不知道当前加入的元素实际高度。

@LavaC 写过个不定高的虚拟瀑布流 demo ，准确的布局还是做得到的，https://list.qcqx.cn/#/list/virtualwaterfall

@Chuckle #9 拟列表一般都是滑到底部后增量加载，类似分页，并不是一次性把所有数据加进 list ，而且计算布局也限制在视口附近的元素，优化手段还是很多的，查找要渲染的元素范围用二分，当然，往下滑动多了，list 还是会很大，可以考虑分数组、按范围计算，甚至上 canvas ，不过一般来说那点数据量 cpu 应付得过来的，总比上万个 dom 元素好多了，至于内存占用，这个没特殊限制倒没大问题，100w 个对象也才多大，重点还是列表布局的渲染，数据量大了怎么搞都是妥协，布局还是得老老实实算。这 demo 写得也一般，但是不定高虚拟瀑布流也能应付无图片的上万条数据。

@Chuckle 后端把图片宽高返回的话，计算量能小点，小红书就是这么干的

虚拟列表是在滚动时计算出要渲染的元素在数组中的索引范围，普通的定高、不定高的计算量不大，很流畅，但是不定高的瀑布流，还伴随着图片加载的话，计算量就很大了，写过个 demo ，https://list.qcqx.cn/#/list/virtualwaterfall

fnMap https://www.v2ex.com/t/1057134 有这个功能