分页参数处理逻辑的最佳实践

　　本文讲的不是如何结合数据库实现分页功能，而是对分页参数pageNum和pageSize缺省时的处理逻辑。结合工做经验，谈谈不一样方案的优缺点，并推导出最佳方案。

 

参数：pageNum, pageSize

pageNum 指的是拉取第几页的数据（也叫记录，下同），从1开始。
pageSize 指的是每页多少条数据。特别地，当pageSize=0时，表明拉取所有数据，此时pageNum无心义。

需求：
1. pageNum和pageSize能不传就尽可能不传，方便使用。

方案A：
pageNum缺省是1
pageSize缺省是0
因此，当两个参数都不传时，天然就是返回所有记录。

优势：规则简单，好理解。
缺点：遇到大表时，开发人员一不当心调用就卡死了。卡死前端，也可能连后端都卡死。
开发人员刚接触一个新API时，正常的想法是什么参数都不传，调用一下看什么反应。

因此需求改成：
1. pageNum和pageSize能不传就尽可能不传，方便使用。
2. 避免不当心返回表的所有记录。

方案B：
pageNum缺省是1
pageSize缺省是20
因此，当两个参数都不传时，就是返回第1页记录。
若要返回所有记录，则必须传pageSize=0。

优势：不传参数时，不管表有多少记录，不再会出现卡死的状况了。
缺点：前端不知道某些接口是有分页的，没传分页参数，某些表（好比管理员表）一开始数据量小没发现问题，使用一段时间后，超过1页了，超过的就显示不出来。这个坑不太容易发现。并且不是一两个接口有这个问题，工做量不小。生产环境修复Bug，得当心谨慎。

　　因此，不传分页参数时，应该如何处理才是最佳作法（最佳实践）是个值得三思的问题。

需求再次修改成：
1. pageNum和pageSize能不传就尽可能不传，方便使用。
2. 避免不当心返回表的所有记录。
3. 避免前端不知道分页机制的存在，没传分页参数，得不到第1页之外的数据。

分析：
若pageNum和pageSize都空，则不能返回所有记录，也不能返回第1页。
既然，不能返回所有，也不能返回第1页，更不能返回第n页，那就只能报错了。

什么条件下报错，报什么错？
有pageNum，有pageSize，正常执行。
有pageNum，有pageSize，且pageSize=0，正常执行。
无pageNum，有pageSize，且pageSize=0，正常执行。
有pageNum，无pageSize，pageSize取默认值，正常执行。
无pageNum，有pageSize，且pageSize不是0，报错：pageNum不能空。
无pageNum，无pageSize，报错：pageNum不能空。

无pageSize，则pageSize是null不是0

方案C：
有pageNum时，若无pageSize，则pageSize设为20。
无pageNum时，若pageSize不是0，则报错，错误信息：pageNum不能空。

优势：
1. 有pageNum时，pageSize能够不传；pageSize传0时，pageNum能够不传，知足需求第1点。
2. pageNum和pageSize都不传时报错，避免了返回所有记录，知足需求第2点。
3. pageNum和pageSize都不传时报错，强迫前端pageNum和pageSize至少传一个，前端也就知道这个接口有分页功能，知足需求第3点。

　　方案C就是最佳实践。我孜孜不倦地追求最佳方案，以不变应万变。

　　By the way, 关于pageSize默认20，成了业界的不成文规定，好像谁也没有要打破的意思，对此，我有见解。没有谁规定一页的默认记录数非20不可。鉴于目前互联网和通讯的发达，我我的推荐一页默认50条记录。

当你遇到一个软件，每次拉取20条记录，每次拉取都要等待一两秒，而你想一想拉取500条记录，操做起来想死的心都有了，你就会以为每页20条，是多么不合理。