分页怎么做

用户体验层面：无限下拉和分页的区别
无限滚动适用于类似Twitter的用户，其中用户实时生成出无穷无尽的数据流，而无需特别查找任何内容，而分页界面适用于人们正在寻找特定项目的搜索结果页面以及用户查看的所有项目的位置信息很重要的情景。
但是现在的移动端产品从用户体验层面看都应该使用无限下拉。

技术方案：
1.类似于Twitter和微博，是有时间线的概念，把关注的feed按时间线展示。
接口设计：游标方案，即每次请求的时候把上一次的最后一条id带上

2.类似于淘宝/京东的商品推荐，或者抖音/快手的视频推荐，推荐的商品，视频也是无尽的。
接口设计： 请求的url上加两个参数page=1 && pageSize=10
如果接口失败或者没有数据，就重试，直到有数据返回。
其中通过曝光去重策略来去除重复的商品或者视频。

3.体量没到淘宝京东这样，推荐的商品是有限的。
方案1:传统分页的方式：算法推荐给出总商品数量，后端根据商品数量给到前端总页数，前端根据总页数判断，不到最后一页，就一直请求，到最后一页，就见底提示了。
这个方案需要对整体的有限的几百条数据进行缓存，否则每次请求推荐，可能会有重复。
方案2:流式分页的方案：和上面无限下拉的的分页方案一样，前端不感知总页数，在请求的url上加两个参数page=1 && pageSize=10，因为数量是有限的，所以见底后需要提示，所以前端还需要知道什么时候数据请求完了，所以这种方案需要在接口返回中增加一个标识，是否有下一页，如果有下一页，那么前端就知道当本次接口没返回数据的情况下，是应该重试，还是见底提示。

经验总结：当商品数量有限的情况下，哪怕是推荐，也尽量使用传统分页，没必要使用流式分页，方案改变引发的沟通成本和开发成本太高，而且没有收益，因为数量有限的情况下，为防止后续分页有数据重复，肯定要在第一页请求的时候，后端缓存数据，（排除按照曝光去重，这个开发成本更高，也排除几百条数据一次返回给前端，前端做分页，这就没后端事了），既然缓存了数据，肯定知道是多少条，在这个基础上搞流式分页，没有意义，流式分页适用的场景还是说在请求后续分页的时候，有新数据产生，直接就把新数据返回给前端，而不是固定的数据。

https://jelly.jd.com/article/6006b1045b6c6a01506c87e9#
https://github.com/Tomorrowxxy/JDHot/blob/master/201706/%E6%B5%81%E5%BC%8F%E5%88%86%E9%A1%B5%E6%96%B9%E6%A1%88%E6%8E%A2%E7%B4%A2.pdf

https://www.jianshu.com/p/4f49f3ec4716