掘金 后端 ( ) • 2024-04-27 09:48
Pagehelper的reasonable配置引起分页失效问题
Pagehelper reasonable

Pagehelper的reasonable配置引起分页失效问题

一个意外的接口请求，引发了刨根问底的冲动

某天突然一个意外地请求，前端是很正常的列表请求，引发了两个问题：

​ 1、get请求有传pageNum和pageSize参数，查询数据库是正常的基础select查询，没有写limit ?,? 分页，也没查到分页配置bean，mybatis拦截器等，但是实现了分页效果

​ 2、请求查询时传了分页，但是永远返回第一页的数据。

一怒之下，必须搞清楚来龙去脉

​ 这让人有点很想了解他怎么实现的冲动，于是开始打断点debug，分析了一波源码。最后两个问题通过阅读源码均解决了，下面描述下两个问题的排查过程

第一个问题排查，没有传入limit，却实现了分页，难道get请求传入pageNum和pageSize就能自动分页，太神奇了吧？

先看下代码结构，简易代码：

//Controller代码：
@GetMapping("/community/getRecordByPage")
@EnablePage
public PageResult getRecordByPage(CommunityRecordDO record) {
    try {
        List<CommunityArSplitRecordDO> list = recordService.getRecordByPage(record);
        return getPageResult(list);
    } catch (Exception e) {
        log.error("xxxxx，MSG:{}", e.getMessage(), e);
        return null;
    }
}

//Service代码：
public List<CommunityRecordDO> getRecordByPage(CommunityRecordDO record) {
    return recordMapper.getRecordByPage(record);
}

//mapper
List<CommunityRecordDO> getRecordByPage(CommunityRecordDO record);

//xml
<select id="getRecordByPage" resultMap="BaseResultMap">
    select
    <include refid="Base_Column_List"/>
    from t_community_ar_split_record
    order by create_time desc
</select>
    
//请求地址
localhost:8080/api/community/getRecordByPage?pageNum=1&pageSize=10

可以看得出，代码结构非常简单，就普通的列表查询，重点：没有写limit ?,? 但是他却实现了分页，给前端返回了分页内容。

排查步骤：

1、项目是springboot，查看了下是否有分页的bean配置，全局搜了，并没有。

2、查看了整个项目的pom.xml文件，有引入pagehelper，这会算是基本找到方向了（问题刚刚开始）

<!-- pagehelper 分页插件 -->
<dependency>
    <groupId>com.github.pagehelper</groupId>
    <artifactId>pagehelper-spring-boot-starter</artifactId>
    <version>${pagehelper.spring.boot.starter.version}</version>
</dependency>

3、有引入插件，那应该需要配置mybatis的拦截器到Spring的bean容器里面啊？以前做SpringMVC的是后均是要配置的，但是全局找项目又没找到，后面想了一下Springboot的自动装配，是不是pagehelper-spring-boot-starter自动装配帮忙配了，搜了一下，果不其然，确实是自动配置了（自动装配果然名不虚传）

image-20240426140656241.png

4、不需要配置拦截器的原因找到了，那我们正常使用pagehelper时一般都是要在执行sql前写一段代码，证明开启了分页的，但是这里也没有写

//分页开启
PageHelper.startPage(pageNum, pageSize);

5、debug执行mapper代理的源码，跟踪到拦截器这一步，确确实实自动加上了limit，很神奇

image-20240426151000856.png

6、然后再往上一步如何赋值的地方溯源跟踪，发现拿到这个page对象时候，确实是已经有默认值了，那在什么时候赋值的呢？继续往后查

image-20240426151406371.png

进入getLocalPage()方法，实际就是一个LOCAL_PAGE对象，还要继续往前，看什么时候set进去的

image-20240426151520838.png

image-20240426151537896.png

在set处打断点，然后根据堆栈往前找，最终找到了原来是源码包做了个注解切面@EnablePage，每次使用这个注解时候，就会走这个切面，然后给全局调用PageHelper.startPage(pageNum, pageSize)

image-20240426151948776.png

image-20240426152100441.png

7、已经找到源头了，那@EnablePage在什么时候加的，然后pageNum和pageSize是从哪里来的，其实问题已经解决了，Controller那一层确实有一个注解，这个注解不是spring注解，还有get请求带上了两个参数，这两个参数就是分页配置参数，无非就是从请求地址获取这两个参数做一个全局的开始分页切面

//请求地址
localhost:8080/api/community/getRecordByPage?pageNum=1&pageSize=10
    
//Controller代码：
@GetMapping("/community/getRecordByPage")
//分页注解
@EnablePage
public PageResult getRecordByPage(CommunityRecordDO record) {
    try {
        List<CommunityArSplitRecordDO> list = recordService.getRecordByPage(record);
        return getPageResult(list);
    } catch (Exception e) {
        log.error("xxxxx，MSG:{}", e.getMessage(), e);
        return null;
    }
}

image-20240426153032544.png

到这，第一个问题已经解决了，本以为加上pagehelper自动配置，都不需要配置mybatis拦截器，也不需要写PageHelper.startPage(pageNum, pageSize)，界面get请求传入pageNum和pageSize就可以实现分页，实则并没有这么牛，框架并不知道你业务，所以不会做这种全局的配置。

第二个问题，count记录只有3条，但是传了pageNum=2，pageSize=10，但是一直返回第一页的3条数据，按道理应该返回空，因为不存在第二页

代码结构不变，跟第一个问题是相同代码。传入pageNum=2，pageSize=10，返回第一页的数据，即使把pageNum改成3，4，5也是返回第一页数据

//请求第一页
localhost:8080/api/community/getRecordByPage?pageNum=1&pageSize=10
//请求第二页
localhost:8080/api/community/getRecordByPage?pageNum=2&pageSize=10
//请求第三页
localhost:8080/api/community/getRecordByPage?pageNum=3&pageSize=10

排查步骤：

1、本次思路也是按照第一个方法的步骤去debug跟踪源码排查，找到page这个对象，查看它的pageNum值是多少

localhost:8080/api/community/getRecordByPage?pageNum=2&pageSize=10

image-20240426154944415.png 可以看到，切面是实质拿到了pageNum=2，那为什么执行时候返回的是第一页数据呢？

2、排查实际执行的sql，debug到getPageSql这个方法，拿到的page对象，pageNum确实是1，那可以猜测，从切面设置为2开始，中途肯定有什么方法让他改变成1

image-20240426160354715.png

3、到这里代码太多，不可能一步步走，此时需要监听pageNum这个字段，看它什么时候变化

第一次赋值是2，跳过

image-20240426160832434.png

第二次赋值也是2，跳过

image-20240426160900582.png

第三次赋值是1，好家伙，就是他了，顺着堆栈往前看，具体是哪里改变的

image-20240426161022836.png

贴一下执行顺序，其实是在分页插件拦截器的afterCount里面有一个重新赋值的setTotal方法，然后对pageNum做了重新计算，一些列操作，把它计算成了1

image-20240426161133397.png

image-20240426161153015.png

image-20240426161211650.png

4、问题找到了，那为啥会自动计算成1呢？其实从备注也看出来了，是为了防止分页不合理

比如：

1、查询页数比实际页数大，防止不合理，会查询最后一页

2、传递一个负数页数，返回第一页

总之这是一个为了防止安全场景考虑的自动计算，主要是靠reasonable=true控制的，因为只有这个字段为true，才会走到pageNum = pages，如果为false，则不会重新赋值，像我的案例，那pageNum应该还是2，不应该是1

问题是找到了，那又想知道reasonable是在什么时候赋值的呢？代码都看到这了，那就把它看完整把，继续监听该字段的变化

此时入参已经是true

image-20240426162049696.png

往上看，入参是一个全局变量，也为true，默认值是false，所以还是有地方改变了

image-20240426162156095.png

image-20240426162239380.png

最终找到是获取配置项的，只有在项目启动初期赋值

image-20240426162321954.png

搜了一下yml，确实有这个值配置

image-20240426162507293.png

到此，问题是已经排查清楚了，是因为在yml配置pagehelper的分页合理化配置，导致了分页一直返回第一页的bug，其实也不算是bug，应该是属于分页合理化考虑，防止本来就没有第二页数据，硬是要查第二页的信息

如果需要正确返回分页信息，三种方式：

1、不配置该字段，默认值就是false

2、配置该字段，设置为false

3、使用PageHelper.startPage的重载方法，把false传入

image-20240426163147928.png

后记

​ 小小的两个bug花了竟然快2个小时，一点点debug分析，观察字段变化，反复请求从头来，真费神费脑，但是结果是快乐的，又通透了一边PageHelper和mybatis的源码流程。

得出最后结论的那一刻，突然想到使用这个分页合理化参数，会导致某种死循环问题，比如代码写法：

int pageNum = 1;
int pageSize = 10;
List<String> result = new ArrayList();
while(true){
    List<String> tempList = mapper.select(pageNum,pageSize);
    if(tempList.isEmpty){
        return;
    }
    result.add(tempList);
    pageNum++;
}

有时候我们做批量导出时，某张表数据量很大的时候，不可能一次性全读出来，那么这时候就会分页取，通过取不到值去结束循环，结果分页到最后一页再往后时，由于分页合理化配置，pageNum++继续增加，结果都是最后一页，那么循环就无法结束，导致死循环。

所以这个参数个人感觉还是使用默认配置false即可，不需要是否合理化，到底合不合理，由业务代码来评估。