“分页”的方式，大家通常怎么处理？

[rogwan]

遇到五种分页方式，大家都怎么处理：

1 、 Discuz! 那种全功能分页：<< 1 2 3 ... 5 6 7 ... 31 32 33 >>

2 、第 2 种是第 1 种的简化版： < 上一页 6 下一页 >

3 、第 3 种是不显示页码，只显示：点击加载更多 / 或点击加载下一页

4 、第 4 种是页面滚动到底部，自动加载下一页

5 、第 5 种是第 4 种的加强版，在用户访问第 6 页时，就预加载第 7 页了（用户感觉不到已经加载了下一页）。

[iRiven]

讨厌无限下拉，上下页最舒服

[Yunhao]

有时候我只是想看一下页面的 footer ，那些自动加载的让我很无奈

[alvy]

python pagination

[hasbug]

纠正一下
比较喜欢这种：
下拉上一页，上滑下一页，永远只显示一页的内容（前端路由）

[Reign]

看性能要求，如果千万级 or 亿级数据， 1 这种方式就有点吃力了，因为 1 这种方式 mysql 只能 offset limit 方式查询。所以只能 2 、 3 、 4 、 5

[solidsnake]

按需

[houshengzi]

@Reign 难道其他 4 种不是 offset limit ？

[gdtv]

@Reign
@houshengzi
同问，难道其他 4 种不是 offset limit ？

[gdtv]

@houshengzi
@Reign
哦，明白了，其他方式应该是 where time<xxxx limit xxx ，不用 offset

[willakira]

这么明显的 A/B test 需求…
不要瞎选，你把几个关键指标的监控放好，然后做 A/B Test ，每个样式给 5%-10%的用户，然后看看哪种样式的结果最好就行。例如停留时间，翻页点击等等

[AlisaDestiny]

@Yunhao +1.自动加载更多真的很烦。

[yidinghe]

在性能方面来说，不跳页（或者说不往后跳页，往前跳可以通过缓存解决）是最好的，因为这时候查询就不需要 skip 了，不管从什么位置开始查，所需要的时间都是一样的。

[rocksolid]

最讨厌第一种，特别是没有跳页的

[alex321]

就产品设计初衷选择而言，在后台管理量级列表上 1 很实用，当然还有个跳页，比如各种 CMS 、 CRM 和 ERP ；在轻量级别的触屏版上 2 更加合适，比如 Google 触屏版的搜索；追求简洁设计的情况下，在 APP 上更多的会是 3 、 4 ，这个太多了就不说了。
有交互的，我更加倾向使用 1 和 4 的集合版本，通过鼠标或者手指滑动触发加载前 3~5 页，然后后续显示分页组件，类似色魔张大妈的效果。

然后，多嘴一下，我觉得 layui 的分页组件挺不错， https://www.layui.com/doc/modules/laypage.html 。

[BlueWolf]

我就是想看总共有多少条记录 4 5 不满足吧

[jiangzhuo]

在第一页的时候把 querystring 的参数都列全 让用户自己改 querystring 去
比如
https://www.v2ex.com/t/352832?page=<页>&skip=<跳过>&limit=<限制>
用户想翻页或者看第几条就自己改参数就好了

[mcfog]

所以后端接口直接提供 offset 和 limit 参数，前端随便玩去吧

[phithon]

非常讨厌下拉加载，不是社交类型的网站（用户喜欢刷刷刷的）千万别用。。。有的博客用这种方式，导致想找资料和文章，非常不方便。

[debye]

下拉加载都是 app 的模式， pc 还是第一种比较好
不过确实要按照产品王的来最好

[anthozoan77]

整理得很全，收藏。