前言
各位老铁们，我又来啦~ 在经过了一个国庆假期加班的项目紧张时期后，终于终于也克服了自己的懒筋，来写点文字吧！ 国庆节之前在日常测试一个分页查询接口，库里一种10条数据，一页10条，查询第1页，结果显示10条，这是正常的，但是当我随心所欲地改参数为查询第3页、第5页，每页记录数不变的情况下，结果还是显示一模一样的10条，啊~ 这~~，看起来神奇的存在！
pagehelper 分页查询失效
postman 分页查询测试
我的库里一共10条数据，当查询第六页，每页显示两条记录时，按道理应该查询为空啊，但是竟然查出来数据了，此处隐约觉得是自己写的bug😌（后来一想有种侥幸心理：按照页面上方式普通用户应该看不出来这个问题）。
问题分析与解决
前提：分页查询时page(pageNum)为3，pageSize为10；
看控制台的sql执行语句，先来看正常的分页查询打印出来的分页查询：
当我们传输page(pageNum)、pageSize两个参数时，拦截器会在原sql语句后面拼接上limit ?,? 两个参数分别为(pageNumber-1)*pageSize,pagesize
再来看上面翻车的分页查询语句：好家伙，limit ？， 少给它拼接了一个参数呐！！！
就去debug了PageHelper的代码，发现果然有猫腻：
pages为查询的总页数，pageNum 为当前查询页数；
当reasonable为true 并且记录的总页数> 查询页数时，查询页数会被更新为记录的总页数；
所以，当我在传参时，满足pageNum * pageSize > pages 条件，pageNum 会被置为pages ，对应到postman测试时，库中满足条件的总记录数为10，当pageNum 为6 ，pageSize为2时，pages为10/2=5; 此时的pageNum>pages,所以pageNum = 5, 显示的是第5页的数据；当pageNum为3，pageSize为10时，pages为10/10=1; 此时的pageNum > pages,所以pageNum=1, 显示的是第1页的数据；
reasonable 是pagehelper分页合理化的设置项，默认是false;
当设置reasonable=true时，如果用户传入的页数已经大于了总页数，则会将用户传入的pageNum修改为总页数pages，默认查询最后一页的数据，当禁用此参数或者设置为false时，当用户传入的页数已经大于了总页数，会返回为空；
再来看我的配置文件,果然是它的锅（复制过来的时候瞎搞😠）：
当我把此配置项去掉后，再来看查询结果正常了：
还可以在分页查询时指定此参数：
调用startPage时传入reasonable参数 为false
小知识
pagehelper的reasonable 默认为false，遇到查询页数大于总页数时，查询为空；当reasonable设置为true时，遇到查询页数大于总页数时，查询最后一页数据；
参考链接
www.cnblogs.com/lykbk/p/sds… blog.csdn.net/shenchaohao…
小结
注意细节，每天进步一点点 ！
