更新时间：2026年10月11日

分页控件先要说明用户正在看哪一段记录，再规定位置怎样变化：翻页保留筛选和排序，修改筛选后从首个结果开始，从详情返回时恢复原列表条件与所在位置。每页条数、总量变化和加载失败也要有对应规则，否则一排清楚的页码仍可能让人迷路。

以设备巡检台账为例：共有137条记录，每页20条，巡检人员在第4页打开INSP-068，核对后还要继续查看后面的记录。可以用Pixso交互原型把列表、详情和返回路径连起来，先确认这段浏览任务能否接得上。

先判断用户是否需要按页找回位置

这张台账需要逐条核对、进入详情并返回，明确的位置比持续追加新内容更重要。若列表只有几条记录，直接显示全部内容往往更简单；如果用户主要随意浏览图片，可能更适合加载更多。选择方式应看任务，而不是看组件库里哪一种控件更漂亮。

分页也不同于分步填写表单。巡检台账的第4页与第5页是同类记录的不同片段，用户可以选择查看哪一页；申请流程里的下一步则有先后关系，可能还需要校验当前输入。GOV.UK的分页规范也将内容浏览与线性表单流程分开处理。

让第4页对应到一段真实记录

本例第4页显示第61–80条，共137条；每页20条，共7页，最后一页是第121–137条。页码、范围、条数和总量必须相互对应。不能表格显示了20行，页脚却还写着“第1–10条”。

页数很多时可以折叠中间页码，但要让当前页和相邻页可辨认。若省略号只是表示还有内容，就不应给它普通页码的点击样式；若它确实支持跳转，需要让操作结果可理解。

有些列表拿不到准确总数，只知道是否还有下一批。这时可以显示已加载的范围与下一页入口，不必伪造“共137条”或一个无法兑现的末页按钮。总记录数、符合筛选的记录数和当前加载数是三种不同口径，界面文案应说清使用哪一种。

先给常见操作写出明确结果，再画默认态。本例采用以下规则，其他项目可以选择不同方案，但同一列表不能前后矛盾。

修改每页数量也可以选择尽量保留原来的首条记录。例如原先从第61条开始，换成50条后定位到包含该记录的一页。但这涉及范围计算和滚动行为，需要设计、研发共同确定，不能把两种方案混在不同入口中。

清除筛选时是否恢复筛选前的第4页，也应单独决定。如果界面没有传达保留历史位置的含义，回到全部结果的第一页通常更容易解释。浏览器返回、页面内返回和重新进入菜单则可能代表不同操作，不能默认它们必须共享所有历史状态。

点击第5页后，如果页码立即选中5，列表却还停留在61–80条，用户可能误以为这些就是新结果。加载期间可以保留原列表并明确标出正在载入，也可以展示结构一致的占位内容；关键是不要让旧记录与新页码组成一个看似已经完成的画面。

请求失败时保留用户原有条件，给出“第5页未加载成功，重试”这样的反馈。是否回到第4页、是否保留第5页的请求入口要保持一致。快速连续点击多个页码时，最终列表要对应最后一次有效操作，不能让迟到的旧结果覆盖新选择；具体请求处理机制由研发实现，设计稿要交付用户看到的顺序。

记录也可能在浏览期间变化。比如最后一页的记录被删除，原第7页不再存在，本例返回最近的有效页并提示“记录已更新，已显示第6页”。如果总数暂时无法刷新，就不要同时显示一个确定但已失效的计数。对需要严谨审阅的列表，还要与业务方确认是否使用某一时刻的数据快照，分页控件本身不能保证数据不变。

将第4页列表、INSP-068详情和返回后的列表并排放在画布中，三处都保留相同的筛选条件；返回画板仍突出INSP-068，方便检查浏览任务是否接得上。

演示时先从列表打开记录，查看设备、巡检日期和结果，再返回。随后增加“需复检”的筛选，结果缩小为9条，观察是否从首个结果开始。原型用具体状态呈现这条路径，查询保存与真实数据更新的规则仍要作为交互说明交给研发。

最后用键盘和窄屏检查分页区：当前页不能只靠颜色区分；按钮有清楚名称和焦点状态；进入详情后返回，焦点应落到可理解的位置。手机上可以把条数选择与页码分行，不要把所有控件挤成一排小热区。

如果这张列表还需要勾选记录并跨页处理，下一步再看跨页全选与批量操作的范围规则。浏览位置和选择集合需要配合设计，但它们不是同一份状态。