Load More顾名思义就是加载更多的意思。

在App里是一个最常见的场景，就是一个列表一直往下，直到没有了内容为止。

比如上购物网站，你搜索一个东西，就可以一直往下找，除非真没有东西了。

而在PC那个时代，绝大部分的做法是通过翻页去做的。但是翻页有一个很头疼的问题，就是如果当前有数据更新，那么你翻到下一页的时候，第一条展示的信息就是你上一页看到的最后一条信息。

这个时候，你会感觉很不爽。

但是，在App里是没有的，它是可以保证不重复的，那它是怎么做到的呢？

实现

最开始，我想的是，可以先把筛选出来的数据先存起来，然后，下次请求的时候再去取。

这种情况，对于小数据量还好说，大数量时，如果筛选再一多的话，那这就意味着需要大量的存储空间。

本质想的就是以空间换时间的概念，但这越想越感觉不靠谱。

那，这个应该怎么做呢？

首先，肯定需要记录一个数据，这个数据可以是当前请求结尾的数据，或是下一次开始的数据，这个就需要根据自己的实际情况去做对应的处理。

一般的做法都是记录下一次开始的数据，主要是为了避免最后一次为空的情况。

我们举个简单例子：需要实现一个接口，查看MySQL的notes表里的所有数据，按照创建时间倒叙输出。

条件是：时间倒叙，而我们数据库表设计的时候是按照id自增的方式做的。那么这个做法可以直接用order by id DESC。

现在我们设计的接口数据是：

// /api/notes?startCursor=xx&limit=20
{
	"startCursor": "xx",
	"list": [{}], // 20条
	"endCursor": ""
}

这块startCursor数据，我们就可以直接用id，即我们执行的SQL代码是：

SELECT * FROM notes WHERE id <= xx ORDER BY id DESC limit 21;

然后，我们通过判断返回的数据列表是否等于21，如果等于就代表还有数据，否则就代表没有数据。

// 数据长度大于20情况
{
	"startCursor": "xx",
	"list": [{}], // 20条
	"endCursor": "last value of id"
}
// 数据长度小于等于20情况
{
	"startCursor": "xx",
	"list": [{}], // 默认返回的数据条数
	"endCursor": "0" // 结束了
}

这样一来就实现了，我们说的LoadMore接口了。

反之，其他实现的话，原理是类似的。