不过相对于普通的page+size分页方式，这样的接口请求势必会慢一些（因为普通的分页可能一页返回不了固定条数的数据，而这个在内部可能执行了多次获取数据的操作）。
不过用于一些实时性要求强的接口上，我个人觉得这样的实现方式对用户会更友好一些。
两者之间的比较
这两种方式都是很不错的分页方式，第一种更常见一些，而第二种也不是灵丹妙药，只是在某些情况下可能会好一些。
第一种方式可能更多的会应用在B端，一些工单、报表、归档数据之类的。
而第二种可能就是C端用会比较好一些，毕竟提供给用户的产品；
在PC页面可能是一个分页表格，第一个展示10条，第二页展示出来8条，但是第三页又变成了10条，这对用户体验来说简直是个灾难。
而在移动端页面可能会相对好一些，类似无限滚动的瀑布流，但是也会出现用户加载一次出现2条数据，又加载了一次出现了8条数据，在非首页这样的情况还是勉强可以接受的，但是如果首页就出现了2条数据，啧啧。
而用第二种，游标cursor的方式能够保证每次接口返回数据都是size条，如果不够了，那就说明后边没有数据了。
对用户来说体验会更好一些。（当然了，如果列表没有什么过滤条件，就是一个普通的展示，那么建议使用第一种，没有必要添加这些逻辑处理了）
小结
当然了，这只是从服务端能够做到的一些分页相关的处理，但是这依然没有解决所有的问题，类似一些更新速度较快的列表，排行榜之类的，每秒钟的数据可能都在变化，有可能第一次请求的时候，用户A在第十名，而第二次请求接口的时候用户A在第十一名，那么两次接口都会存在用户A的记录。
针对这样的情况，客户端也要做相应的去重处理，但是这样一去重就会导致数据量的减少。
这又是一个很大的话题了，不打算展开来讲。。
一个简单的欺骗用户的方式，就是一次接口请求16条，展示10条，剩余6条存在本地下次接口拼接进去再展示。
文中如果有什么错误，或者关于分页各位有更好的实现方式、自己喜欢的方式，不妨交流一番。
参考资料
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对脚本之家的支持。
您可能感兴趣的文章: