很 cool 很特别！ https://i.imgur.com/L62ZP7V.png

什么手机都差不多，手机卡套餐给力就行，软件就把谷歌全家桶装上，还有啥区别。

@Chuckle 还有 navigator.userAgentData.brands ，可以获取浏览器的信息

window.chrome 这个对象，edge 和 chrome 的属性有差异，比如 edge 多了 edgeQuickSearch 等。前端针对性的区分还是很多的办法的，api 和对象多多少少都有差异。

已找到，此帖完结

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

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

@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 有这个功能 https://i.imgur.com/agAJ0Rd.png

蔚蓝共勉，经验+3.jpg

@imlonghao 确实该改改，太草班了，先提取出 Origin 的域名再去对比好点

挺好的，装了再说，vscode 不知不觉已经装了 200+插件了（

hexo 静态、存储桶、cdn ，都不用服务器，markdown 写完就推到存储桶里再刷新下 cdn ，用 git 同步和备份数据，相比于动态站跑路也快，文章 md 文件都在你本地和 git 仓库里

为了方便，我拿 node 写后端先 cv 上这个中间件，获取请求头的 origin ，看是否在白名单域名里，再让 options 快速响应 https://i.imgur.com/iAEKPPE.png