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

[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 页了（用户感觉不到已经加载了下一页）。

[torbrowserbridge]

按照产品汪的需求来...

[yahon]

还有就是没有分页按钮，通过事件触发加载下一页（更多）

[rogwan]

我喜欢第 2 种， PM 说现在流行第 4 ， 5 种。

[rogwan]

@yahon 比如，什么事件？

[dong3580]

我一般都是用第一种，后面再来个 跳转到[x]页 面

[crysislinux]

实际体验来说，还是 1 比较好。。

[Troevil]

如果筛选条件过多, 能不算 total 就不算 total 呗

[mfu]

第 4 第 5 种的缺点是无法从第 1 页直接跳到第 10 页。

[yang2yang]

突然发现对于后台来说，好像都一样，只要你传参数过来......

[zioc]

按照需求来。

1 、有必要跳页，一般出现在作业系统的查询页，比如订单管理
2 、过时了，但比较容易实现
3 4 5 、没有必要跳页，这样比较简洁，怎么加载看需求

[lany]

比较喜欢 3

[yahon]

@rogwan 比如滚动到底部自动加载下一页，通过鼠标左右箭头翻页

[zjqzxc]

移动端用 4 ， 5 ：手机上点那一堆挨那么近的小页码很容易出错
pc 端看需求，只用 1 或者 1 和 4 ， 5 结合；页面顶端使用方式 1 ，下拉到底部自动加载下一页

当然最重要的是看 pm 怎么说

[yejinmo]

我只想点个 footer 上的链接

你却一直在加载下一页

[my101du]

作为程序员，在测试的时候比较喜欢能操控到所有页面，一般是列出 1~N 的链接。顺便还添加一个 input 可以直接跳转。

但是上线的时候，一般留个 1 2 3 .... N-2 N-1 N 以及 上一页 /下一页 第一页 /最后一页 的按钮

[yankbytes]

个人感觉看场景吧，如果像是微博或者知乎那样的信息流结构，感觉 4 、 5 比较适用，如果像是订单之类的可能很多时候我都不会点击下一页，那么感觉 1 比较合适。可以加 telemetry 观测用户行为然后决定？

[gdtv]

我喜欢第一种,非常极其十分强烈讨厌第 4 种和第 5 种, 原因见我刚发的帖子 https://www.v2ex.com/t/352824

[Antidictator]

@gdtv 我也超级讨厌第 4 种，原因是我花了好几个小时还是找不到在知乎看到的那个回答。好气哦！！！！！！

[hasbug]

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

[hasbug]

@hasbug 写反了，哈哈哈。

[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]

整理得很全，收藏。

[king2014]

原理一样,只是显示效果,这个你觉得哪个好选哪个

[Quaintjade]

如果只是表格数据，我喜欢不分页……
http://mleibman.github.io/SlickGrid/examples/example-optimizing-dataview.html
http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records

如果要分页，我还是喜欢第一种。

[BoiledEgg]

最好不要第一种，省的 count 算总页数

[ivvei]

1 的方式 比较吃性能。总数少还行，总数太大的话有点压力。 2 感觉最简单，体验也不错，加个跳页就完美了。 3 4 5 都给我滚……

[atnopc]

第一种的优化,不大量显示页码
只针对当前页显示前 3 和后 3 页的直连外加一个用户自选跳转

[wjh3936]

我在上一个项目，因为没要求就做了 4 ，而且也没有加载动画哈哈滑到底卡一下就加载了

[misaka20038numbe]

3,4,5 在电脑上是反人类的行为，当下拉多次之后右侧的滚动条会越来越短，如果这时我想回去看之前的内容，将会越来越难。

[eseeker]

@Yunhao 我也想说这个问题

[changwei]

@yejinmo 对，淘宝就是这个样子，搞不懂既然这样设计，那 footer 存在的意义是什么？

[flowfire]

显示 《 < 1 ... 56789 ... 12 > 》
我 github 上有一个 js 写的翻页方法，可以直接拿来 new

[Phariel]

自动加载太多非常烦，我明明是要去看 footer 里的内容的，但是如果要看到 footer 我还有很长的路要走，全是自动加载，烦死了。

[Limius]

@misaka20038numbe 完全可以拉下来自动加载，同时保留页数指示，可以随便跳。

[340244120]

得看场景呀 比如看小说 你用 2,3,4,5 试试

[Coder0]

论坛帖子这种一般是 1 ，因为随时可能被回复顶上来
4,5 适合 APP 每日推送新闻的那种，最新的东西一般都在上面 找几天前的东西这种需求比较少

[mingyun]

第二种，非常讨厌 4,5 因为很难找，也不知道什么时候刷到头

[shayuvpn0001]

@gdtv
@yejinmo
@Antidictator
@phithon
@Phariel

我很想问候一下整出 3 ， 4 ， 5 这种必须要一页页翻的脑残设计 or 前端 or 产品，你们的灵感是不是来自于拉不尽的隔夜屎？

[him007]

不喜欢第 4 、第 5 种

[wdlth]

只显示首页、前一页、当前页和下一页，点击某个区域后才会查询总数返回末页，因为数据量过大时，查记录总数用于分页耗费太多时间了。

[Antidictator]

@shayuvpn0001 我怎么有种感觉这句话是你对我们说的。。。

[zhudou]

恶心微博的信息流。

[daemonghost]

这个应该是产品的事吧，得看具体的场景啊。

[shayuvpn0001]

@Antidictator 开发很多时候都是替上面这几种人背锅啊～ 习惯就好了～ 哈哈