分页对于一个前端程序员来说，真是太熟悉不过了；因为对于列表数据呈现，如果没有做分页处理，那就是不负责的表现，后端亦是如此。

借着刚进来慕课网，就来总结一下，关于分页的一些问题，大家来讨论一下。

相信大多数接到产品提分页需求时，基本都是满口答应的。的确，单单做一个分页展示真的不难，基于前后端分离开发方式下的分页，前后端只需要约定如下接口。

//上行参数
{
    data:{
        page:1,
        size:10
    }
}

//下行参数
{
    code:200,
    msg:'success',
    data:{
        count:100,
        list:[{}] //10个item
    }
}

剩下的事情就是前端去展示，分页组件线上也比较多，随便找一个就可以了，做完给产品一看。

嗯，不错，完美。

但是，这样就真的完了吗？

事实上并非如此，当我们的列表为空时，是否需要空数据 UI 显示？

当数据仅仅只有一页时，是否需要展示分页控件？Google 的搜索结果是仅有一页结果不显示分页控件。

当我们翻页到最后一页，然后删除数据时问题就显示出来了，最后一页就只有一条数据，当我点击删除按钮之后，发现页面空了，如果你无视这样的糟糕体验那就没有下文了。

我相信一个有信仰的产品或者一个有信仰的前端，是不会无视这样的体验的。对于上面的场景，前端可以稍微处理一下，删除时判断当前是否是最后一页，是否只有一天，删除操作之后页码-1即可。

但是，由此我想抛出一个分页数据同步的问题。这个问题在无限下拉分页的时候应该尤为突出。

当我们在客户端下拉加载的时候，此时数据库插入了一条新数据，不出意外的话，再次下拉将会出现一条重复的数据的，当我们删除一条数据库数据时，对应的就是会丢失一条数据，这个问题在某网站-XX都是产品经理 是没有处理的。

如果数据不会删除，仅新增，我们之前采用的方案是通过加时间戳的方式，也就是请求数据的时候，记下请求第一页时的时间戳，而后的请求都带上这个时间戳，后端在查询数据库的时候，过滤掉这个时间戳之后新增的数据即可。这样就不会有重复数据了。

如果数据可删除的，上面的方案可能无法彻底解决数据不一致的问题，勤劳智慧的后端给出的方案是，修改分页请求的 Api 协议。

//上行参数
{
    data:{
        lastId:0,
        size:10
    }
}

//下行参数
{
    code:200,
    msg:'success',
    data:{
        count:100,
        list:[{}] //10个item
    }
}

将我们的页码参数换成 最后一个数据的 id , 如果是第一页则传 0，后端此时取数据的时候，根据 id 往后取 10（一页）的 条数据，这样无论数据是被删除了还是新增了数据，都能够确保每页数据的一致性。

在前端的工作中，有很多的小细节，至于我们如何对待，仁者见仁，智者见智；以上，仅代表个人的思考，那你面对分页的问题是如何对待的呢？