API 分页

集合接口需要分页:偏移分页简单但深翻页慢且数据变动时会漏项或重复,游标分页按稳定位置继续翻页,更适合大集合与实时数据。

分页为什么要设计

集合接口必须分页,否则一次返回全量数据既拖慢响应,也容易压垮数据库。偏移分页用页码与条数描述位置,实现简单,但深翻页需要扫描并丢弃前面所有行,且翻页期间数据增删会造成漏项或重复;游标分页把位置编码成不透明游标,天然稳定且高效。

怎么选

面向用户的后台列表,页码跳转是刚需,可以保留偏移分页并限制最大页深;面向数据同步与导出的大集合,用游标分页或时间窗,避开深翻页扫描。无论哪种方式都必须定义稳定排序键,并包含一个唯一兜底键,否则相同排序值的顺序不稳定,翻页仍会漏或重。

分页方式

方式请求形态适用与代价
偏移分页页码加每页条数实现简单;深翻页慢,增删会错位
游标分页不透明游标加条数稳定高效;不能随机跳页
时间窗起止时间加条数适合日志流;需处理边界重叠
键集分页上一页最后一条的排序值高效稳定;要求排序键单调可比较

基本信息

排序键必须包含唯一兜底键,例如主键
总数统计大表精确计数代价高,可返回近似值或不返回
页深上限限制最大页深,超出时引导收窄查询条件
一致性需在文档中说明翻页期间数据变动的语义

典型使用场景

  • 后台管理列表:需要页码跳转,允许一定深翻页
  • 数据导出:分片拉取全量数据,用游标避免重复与遗漏
  • 增量同步:按更新时间游标持续拉取变更
  • 日志流浏览:时间窗加游标组合使用
  • 移动端加载更多:游标分页降低无效扫描
分页要定义稳定排序键,包含唯一兜底键;只按创建时间排序时,同一毫秒内的多条记录顺序不稳定,翻页会出现漏项或重复。

易错点

  • 用偏移分页暴露深翻页入口,数据库扫描开销随页码线性增长
  • 排序键存在重复值且无兜底键,翻页出现乱序与漏项
  • 游标未做签名或校验,客户端可构造任意游标探测数据
  • 分页期间数据被修改,调用方把重复记录当作新增数据写入下游

数据来源与参考

  • Google API 设计指南:Pagination
  • Microsoft REST API Guidelines:Pagination
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌