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

　　本文讲的不是如何结合数据库实现分页功能，而是对分页参数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页，那就只能报错了。

什么条件下报错，报什么错？
1. 有pageNum，有pageSize，正常执行。
2. 有pageNum，有pageSize，且pageSize=0，正常执行。
3. 无pageNum，有pageSize，且pageSize=0，正常执行。
4. 有pageNum，无pageSize，pageSize取默认值，正常执行。
5. 无pageNum，有pageSize，且pageSize不是0，报错：pageNum不能空。
7. 无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条，是多么不合理。

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

原文：https://www.cnblogs.com/BillySir/p/14418811.html