背景
最近在开发小程序时，有一个业务场景，需要向上滑动加载更多数据、向下滑动刷新数据的需求。
一接到需求，脑海里立刻就想到了分页。由于数据源可能在加载时发生变化（删除数据或增加数据），那么就可能出现数据重复或者数据丢失的情况。那么，如何分页才能保证不出现重复数据或数据丢失的情况呢。
分页类型
分页，主要分为两种。一种是传统分页，常见于PC端；另一种是流式分页，常见于移动端。
传统分页
传统分页，又叫电梯式分页。常见有，google、百度的搜索页。
传统分页，可以选定指定页进行数据获取。也可以上一页、下一页等操作。
通用后端分页实现SQL查询如下：
# page 页码 limit 每页数量
select * from TABLE_NAME where ... order by ... limit (page -1) * limit, limit
接口与响应体样例
GET /products?page=1&limit=15
// 响应体
{
data: [{...}], // 具体数据
total: 20, // 总数
total_pages: 14 // 总页数
}
虽然，传统分页可以方便地获取指定页数据。但是，可能会出现重复数据、丢失数据的情况。且当页数较大时，查询性能降低。
流式分页
流式分页常见于移动端。移动端有着良好滑动体验，由于移动端屏幕小，可点击的范围不是很大，电梯式分页并不适合。
传统分页的后端逻辑完全可以直接用于流式分页。而且，可以不用提供总数量和总页数，减少请求数据。实现逻辑如图所示
但是会有以下三个问题：
- 数据重复
- 数据缺失
- 效率低（当offset很多时，性能会急剧下降）
流式分页 - 游标分页
游标分页不需要提供当前的页码，只需要当前的游标（位置）用于定位就可以完成查询。
游标分页的SQL实现如下：
# 背景：以创建时间倒序展示作品列表
# $cursor 为上一条列表中最后一个作品的更新时间
# $limit 每页的数量
select * from tbl_work where `update_time` > $cursor order by `update_time` DESC limit $limit
接口与响应体样例
GET /product?limit=15&action=down&next_id=2
// 响应体
{
data: [{ }],
next_id: 1,
}
传统分页的偏移位置是固定的，当数据源的数据新增或者减少时会导致加载数据的重复或丢失。游标分页则不会，当数据源发生更改时，游标的位置也会发生相应变化。
一次性下发ID
为了避免出现重复数据或数据丢失的情况。还有一种分页，通过一次获取所有数据的ID。然后前端根据ids分页，每次将对应页ids发送给后端，获取数据。具体步骤如下：
- 请求第一页之前或时，拉取所有ID列表
- 请求2、3、4页时，传入相应ID列表参数
就一个例子，我司的社区评论区就是这种实现方式。
GET https://api.codemao.cn/web/forums/posts/hots/all
// 响应体
{
items: ["163326", "22223", ... "2222"]
}
请求第一页的接口请求
GET https://api.codemao.cn/web/forums/posts/all?ids=163327,163341,163344,161656,163345,162305,162310,163338,163301,163342,162885,163074,163343,7198,163085,163340,163264,163115,163330,163155
// 响应体
{
items: [{...}]
}
使用缓存
为了避免出现重复数据或者丢失数据，也可以使用缓存的手段，将前几页的数据存入缓存。这样保证每次前几页的数据不会出现重复、丢失的问题。后面页数的数据，则实时从数据库获取。
客户端去重
数据去重，也可以在客户端利用主键等唯一标识，对数据进行去重处理。
