Mybatis-PageHelper分页数据转换后hasNextPage失效问题解析

问题现象

在使用Mybatis-PageHelper进行分页查询时，开发者经常遇到这样的场景：从数据库查询出原始数据列表后，需要将其转换为DTO对象再返回给前端。在这个过程中，可能会发现分页信息中的hasNextPage属性始终为false，即使实际上还有更多数据。

问题根源

这个问题的本质在于PageHelper的分页信息存储机制。当我们使用PageHelper.startPage()方法时，分页信息会被存储在ThreadLocal中，并在查询执行后被清除。如果在数据转换过程中创建了新的PageInfo对象而没有正确传递所有分页参数，就会导致部分分页信息丢失。

解决方案分析

方案一：手动设置关键参数

最简单的解决方案是在创建新的PageInfo对象后，手动设置关键的分页参数：

PageInfo<UserDTO> pageInfo = new PageInfo<>(dtoList);
pageInfo.setTotal(page.getTotal());
pageInfo.setPages(page.getPages());

这种方法虽然简单，但需要开发者清楚地知道哪些参数需要传递，容易遗漏。

方案二：使用PageInfo的convert方法

Mybatis-PageHelper提供了更优雅的解决方案，即使用PageInfo的convert方法：

PageInfo<User> originalPage = new PageInfo<>(dbList);
PageInfo<UserDTO> resultPage = originalPage.convert(user -> {
    // 转换逻辑
    return userDTO;
});

这种方法会自动保留所有分页信息，包括hasNextPage等属性，是最推荐的做法。

方案三：替换列表内容

如果已经完成了数据转换，也可以直接替换原有PageInfo中的列表内容：

PageInfo page = new PageInfo(dbList);
page.setList(convertedList);

这种方法同样能保留完整的分页信息。

最佳实践建议

1. 优先使用convert方法：这是最规范的做法，能确保所有分页信息正确传递。

2. 避免创建新的PageInfo对象：如果必须创建新对象，务必确保所有分页参数都被正确设置。

3. 理解分页参数含义：

   • total：总记录数
   • pages：总页数
   • pageNum：当前页码
   • pageSize：每页大小
   • hasNextPage：是否有下一页

4. 在转换前后验证分页信息：可以在转换前后打印PageInfo对象，确保所有关键参数保持一致。

技术原理深入

Mybatis-PageHelper的分页信息是通过ThreadLocal存储的。当查询执行完成后，这些信息会被封装到Page对象中。如果我们直接操作查询结果列表而不保留原始的Page对象，就会丢失这些分页信息。

hasNextPage属性的计算依赖于总记录数(total)和当前页码(pageNum)、每页大小(pageSize)。当这些参数不完整或不正确时，hasNextPage的计算结果就会出现偏差。

通过上述解决方案，我们确保了分页信息的完整性，从而保证了hasNextPage等属性的正确性。理解这一点对于处理复杂的分页场景非常重要。