页码、加载更多还是无限滑：vibe 项目的列表浏览模式怎么选

列表翻页是产品里最不起眼、也最容易被做砸的部分。用户每天都在翻列表：订单、文章、商品、消息、文件。翻页做对了，没人会夸你；做错了，用户会立刻感觉到：刚看到一半的东西不见了、点返回回到了顶部、页脚永远点不到、越翻越卡。更麻烦的是，这些问题往往不在演示里出现，只在真实数据量和真实使用路径下才暴露。

本指南讲四种列表浏览模式怎么选、各自的细节怎么做、数据层有哪些坑，以及上线前怎么验收。文中示例产品与人物均为虚构：示例产品叫“青禾市集”（一个虚构的二手闲置交易应用），示例用户叫小陈（虚构人物）。

先定性：用户在列表里到底在干什么

选模式之前，先问用户在列表里执行的是哪种任务。不同的任务对翻页的要求完全不同。

第一种是“找一个确定的东西”：小陈要找上周买过的那台咖啡机。他有明确目标，翻页只是手段，越快定位越好。这种任务需要可跳转、可搜索、可定位：页码、跳页、排序、筛选，缺一不可。

第二种是“逛逛看有什么”：小陈周末闲着，随便刷刷附近的闲置物品。没有明确目标，浏览本身就是目的，流畅和沉浸感最重要。这种任务适合无限滚动，但前提是用户不需要回头找。

第三种是“处理一批东西”：小陈要把 30 条待发货订单逐一核对。这种任务需要稳定、可复核的位置感：做到第几条了、还剩几条、刚才那条处理完没有。翻页方式必须让进度看得见、回得去。

第四种是“按顺序读完”：比如按时间读通知、按章节读内容。顺序本身就是信息，翻页不能打乱顺序，也不能悄悄丢条目。

一句话：任务决定模式，而不是审美决定模式。先给你的列表定任务类型，再谈用分页还是无限滚动。

四种模式，各自适合什么

传统分页：底部一排页码，第 1 页、第 2 页……适合“找确定东西”和“处理一批东西”。优点是位置感最强：用户知道自己在第几页、共几页，能直接跳到某一页，能把某一页的链接发给别人；缺点是每次翻页都是一次打断，逛起来不够顺。

“加载更多”按钮：列表底部一个按钮，点一下追加一批。适合介于两者之间的场景：既想逛，又偶尔要停下来。它保留了用户的控制权——加载是用户主动触发的，不会因为滚动就悄悄改变页面长度；同时它也比传统分页顺，因为不需要整页刷新。它的代价是多一次点击，而且按钮文案要写清楚：是“加载更多”还是“显示全部”，两者承诺完全不同。

自动无限滚动：滑到底自动追加。适合纯浏览场景：信息流、图片墙、短视频式列表。优点是沉浸感最强；缺点也最集中：没有页脚落点（页脚内容永远被推到加载之后）、返回后位置容易丢失、用户不知道自己看了多少、也很难分享“看到的那一条”。

虚拟滚动：只渲染可视区域附近的条目，其余用占位撑起高度。适合超长列表（几千上万条）且每条渲染成本高的场景，比如管理后台的大表格。它不是一种“浏览模式”，而是一种性能手段，可以和分页、“加载更多”搭配使用。单独谈“要不要虚拟滚动”之前，先确认列表是不是真的长到了需要它的程度——几百条以内，普通渲染加分页通常就够了。

决策表：按场景直接对号入座

订单、账单、工单、审批记录：传统分页。用户要核对、要回访、要把某一页发给同事，页码和链接是刚需。

文章列表、商品浏览、图片墙：看任务。目标明确的搜索结果用分页或“加载更多”；纯闲逛的信息流可以用无限滚动，但要同时提供“回到顶部”和位置恢复。

通知、动态、消息记录：按时间顺序读的场景，优先“加载更多”或分页，避免无限滚动打乱“已读到哪里”的边界。

管理后台大表格：分页 + 虚拟滚动组合，页内条数可调（20 / 50 / 100），并保留排序与筛选状态。

移动端要特别注意：手机屏幕一次只能看几条，用户翻页的频率比桌面高得多；页码按钮要够大、间距够宽；无限滚动在移动端更容易触发误操作（比如想点页脚却触发了加载）。

传统分页的细节清单

页码怎么呈现：不要把 1 到 200 页全铺出来。常见做法是显示当前页前后各两页，首末页常驻，中间用省略号；当前页必须一眼可辨（颜色、加粗、下划线至少占其一），且当前页不可再点——点了没反应的按钮是最差的反馈。

每页几条：给用户选择权，但默认要合理。管理类列表默认 20 条，商品类默认 20 到 40 条；提供 20 / 50 / 100 的切换，并且切换后记住选择、回到第 1 页——切了每页条数还停在第 7 页，位置是错的。

跳页：超过 20 页的列表必须提供跳页输入框（“跳至第 __ 页”），并做输入校验：小于 1 或大于总页数时给明确提示，而不是悄悄跳到第 1 页。

URL 与分享：页码、排序、筛选条件要进 URL。这样用户才能把“第 3 页、按价格从低到高”这条链接发给别人，刷新后也还在同一页。页码只存在内存里的分页，刷新就丢，是最常见的半成品形态。

总数与范围提示：列表顶部写“共 1,284 条，第 21–40 条”，而不是只写“第 2 页”。用户靠总数判断任务量，靠范围判断自己有没有看漏。

空页与越界：数据被删到不足一页时，正在看的那一页可能变成空页。正确做法是自动回退到最后一页有数据的页，并提示“该页已无数据，已回到最后一页”，而不是给用户一个空白页让他自己猜。

无限滚动的五个坑，个个都真实发生过

第一，返回后位置丢失。小陈在信息流里滑到第 80 条，点进一条商品看详情，再点返回，页面回到顶部，刚才的位置没了。这是最伤体验的坑，没有之一。解法是恢复滚动位置：返回时按条目 ID 而不是像素值恢复，并且在详情页返回时先恢复已加载的批次，再滚动到对应条目；如果恢复失败，至少给一个“回到你刚才的位置”的入口，而不是让用户重新滑。

第二，页脚不可达。帮助中心、备案信息、退出登录这些链接放在页脚，而无限滚动让页脚永远在“再滑一点”之后。解法是把关键入口从页脚里搬出来：放到顶部导航、侧边栏或个人中心里；页脚只放不需要高频点击的内容。

第三，加载反馈不清。滑到底之后没有任何提示，用户不知道是在加载、还是已经没有更多了。正确做法是三种状态分明：加载中显示骨架或转圈；加载失败显示“加载失败，点击重试”并保留已加载内容；确实没有更多了，明确写“已经到底了”，而不是让用户对着空白继续滑。

第四，性能垮掉。无限滚动最容易养出几千个 DOM 节点：页面越滑越卡，低端手机先扛不住。超过一屏半以外的内容应当回收或虚拟化；图片要懒加载；滚动监听要节流。判断标准很简单：在低端机上连续滑 200 条，帧率和内存都不应明显恶化。

第五，可达性与键盘操作。只用鼠标滚轮能用的无限滚动，对键盘用户和读屏用户是不友好的。必须保证：不用鼠标也能加载更多（按钮或键盘可达的触发点）、加载的新内容能被读屏软件感知到、焦点不会在加载后丢到页面顶部。

数据层：游标与偏移，选错会出灵异问题

前端模式定下来之后，数据层还有一道选择题：分页参数用偏移量（offset）还是游标（cursor）。偏移量是“跳过前 N 条、取 M 条”，简单直观，适合数据基本不动、且要支持跳页的场景；它的毛病是数据变化时会错位——小陈在第 2 页时有人新上架了一条商品，第 3 页的第一条就和第 2 页的最后一条重复了。

游标是“从上一页最后一条之后取 M 条”，用最后一条的唯一排序键（比如创建时间 + ID）做锚点。数据新增或删除时，游标分页不会重复、不会跳号，适合动态列表和无限滚动；它的代价是不支持随意跳页——“跳到第 37 页”在游标体系里没有直接对应的操作。

所以搭配关系是固定的：传统分页配偏移量，跳页才有意义；无限滚动和“加载更多”配游标，稳定性才有保障。混用是最常见的坑：用偏移量做无限滚动，数据一变就出现重复条目，用户会以为产品出了 bug——实际上是分页参数选错了。

还有一条容易被忽略的规则：排序必须稳定。只按“发布时间”排序是不够的，同一秒发布的两条记录顺序会飘；排序键要加一个唯一字段兜底，比如“发布时间倒序、ID 倒序”。排序不稳定，翻页就会出现同一条在两页都出现、或某条永远翻不到的灵异现象。

“加载更多”的混合打法：很多团队的实际最优解

如果拿不准用分页还是无限滚动，优先考虑“加载更多”按钮，再配两点补强：第一，按钮下方同时显示“已加载 60 / 共 1,284 条”，给用户进度感；第二，支持返回位置恢复，点进详情再回来，仍停在原来的批次和条目。

这个组合的好处是进可攻退可守：想逛的用户连续点几次就能一直看，想停的用户随时能停；页脚始终可达（按钮之后就是页脚）；加载是用户主动触发的，不会因为网络抖动就悄悄改变页面。很多内容型和管理型产品最后都落在这个方案上，不是因为它时髦，而是因为它在各种任务类型下都不翻车。

一个反模式要避免：“加载更多”点完之后自动变成无限滚动，或者反过来。模式在一次会话里应当保持一致，中途切换会让用户对“页面到底有多长”彻底失去判断。

测试矩阵：上线前按这张表跑一遍

数据量维度：0 条、1 条、刚好一页、刚好一页多 1 条、1,000 条以上，各跑一遍翻页流程。刚好一页多 1 条是最容易暴露“多余的下一页按钮”的边界。

变化维度：翻页过程中新增一条、删除一条、修改排序字段，检查有没有重复、跳号、空白页。

导航维度：从列表进详情再返回，位置是否恢复；刷新页面，页码与筛选是否还在；把某一页链接发给另一个人，对方打开是不是同一页。

网络维度：弱网下连续翻页，加载失败后重试是否保留已加载内容；快速连续点下一页，有没有并发请求互相覆盖。

设备维度：低端机滑 200 条看帧率与内存；键盘全程操作一遍；读屏软件走一遍加载流程。

上线清单（十项）

一、任务类型已定：找东西、闲逛、处理一批、按序读完，四选一写进需求文档。二、模式与任务匹配，决策表有据可查。三、页码呈现规则完整：当前页可辨、省略号规则、跳页校验。四、每页条数可调且切换后回到第 1 页。五、页码、排序、筛选进 URL，可分享、可刷新。六、总数与范围提示齐全（共几条、第几到第几条）。七、空页与越界有回退与提示。八、无限滚动五项全过：位置恢复、页脚可达、加载三态、性能、键盘与读屏。九、分页参数与模式配对：分页用偏移、滚动用游标，排序键唯一兜底。十、测试矩阵五维全跑，边界用例（0 条、一页多 1 条）留有记录。

最后提醒一句：翻页不是视觉问题，是信任问题。用户把“下一页还有我要的东西”这份信任交给你的列表，你的翻页方式每一次都不能辜负它——位置不能丢、条目不能重复、总数不能骗人。把这三条守住，模式选哪个都不会错得太离谱；守不住，再顺滑的滚动也只是让用户更快地失望。

从分页改到“加载更多”：一次迁移的实操步骤

很多团队不是从零选模式，而是要从一种模式迁到另一种。最常见的迁移是从传统分页改到“加载更多”，动机通常是移动端占比上来了、用户抱怨翻页打断感太强。迁移时最容易翻车的地方不是前端组件，而是旧链接与旧习惯。

第一步，先保住 URL 语义。旧的分页链接（比如 ?page=3）不能一夜之间全部失效：已经发出去的链接、搜索引擎收录的页面、用户收藏的某一页，都指着这些地址。迁移后，带页码参数的链接应当仍能打开，并定位到对应批次的起始位置，而不是跳回第 1 页或报 404。这一条做不到，迁移就是一次外链事故。

第二步，分批灰度，不要全量切换。先拿一个列表做试点（比如文章列表），跑两周，对比三组指标：列表页的跳出率、详情页的进入率、用户反馈里关于翻页的投诉量。三组指标里有两组变差，就回滚——模式迁移不是审美升级，是行为实验。

第三步，处理“第 N 页”这个概念的残留。客服话术、帮助文档、运营给用户发的教程里，可能都写着“翻到第 3 页”。模式变了，这些文字要同步改，否则用户按旧教程操作却找不到页码，会以为是产品坏了。迁移清单里要有一项专门检查站内外的帮助文本。

第四步，监控要跟上。迁移后第一周，每天看三个数字：加载失败率、平均加载批次、用户单次会话浏览的条目数。加载失败率上升说明新模式对弱网更敏感；平均批次暴涨可能意味着用户在无意识地多加载（比如误触）；浏览条目数上升但详情进入率下降，说明用户在“滑”而不是在“看”，沉浸感上来了、目标感下去了。

容易被漏掉的两处细节：无障碍与多语言

无障碍方面，除了前面提到的键盘与读屏，还要检查焦点管理：点“下一页”之后，焦点应当落在新内容区域的开头，而不是留在原地或回到页面顶部；“加载更多”追加内容后，读屏软件应当能播报“已加载 20 条，共 100 条”这类状态变化，而不是悄悄改变页面。颜色方面，当前页的标识不能只靠颜色区分——色弱用户需要同时有加粗、下划线或文字标识。

多语言方面，页码与数量文案要留好复数与语序的余地。中文“共 1,284 条”在英文里是“1,284 items”，在有些语言里数字与名词的顺序、复数形式都不同；“第 21–40 条”这种范围表达也要走本地化字符串，不要在代码里用中文模板硬拼。列表组件的文案一开始就抽成可翻译的 key，后面加语言时才不用返工。