RuoYi框架数据分页功能分析——以角色管理为例

一、实例简介

本文以RuoYi-Vue框架中的角色管理页面为例，分析其数据分页的前后端实现原理。

进入方式：系统管理 → 系统管理 → 角色管理

角色管理页面展示系统中所有角色信息，支持按角色名称、权限字符、状态等条件筛选，并通过分页组件控制每次加载的数据量。

二、为什么要数据分页？

反向思考：如果不做分页，当数据量大、并发访问多时，会带来以下问题：

前端方面：

• 显示问题：数据量过大时页面渲染卡顿，用户体验差
• 内存开销：一次性加载大量数据占用大量浏览器内存
• 数据及时性：数据早已加载完毕，无法反映最新变化

传输方面：

• 速度慢：大量数据传输耗时长
• 占用带宽：无效数据传输浪费网络资源

后端方面：

• 内存开销：一次性查询全量数据占用大量服务器内存

因此，分页是大数据量场景下的必要手段，每次只查询当前页所需的数据。

三、前端源码分析

3.1 分页组件

打开角色管理页面的前端源码文件：

路径：ruoyi-ui/src/views/system/role/index.vue

其中 <pagination> 即为分页组件：

• -show="total>0"：只有后端返回数据时才显示分页栏
• :total="total"：绑定总条数，初始值为0，由后端返回后赋值
• :page.sync="queryParams.pageNum"：当前页码，随用户翻页更新
• :limit.sync="queryParams.pageSize"：每页条数，默认10
• @pagination="getList"：翻页时触发 getList 函数重新请求数据

3.2 函数调用链

函数调用链为：getList → listRole → request（axios）

getList 函数调用 listRole，将 queryParams（包含 pageNum 和 pageSize）作为参数传入，并将响应中的 response.rows 赋值给列表数据，response.total 赋值给 total，从而驱动分页组件显示正确的总页数。

listRole 来自 @/api/system/role，通过 import 引入。

listRole 通过 axios 发起 GET 请求，接口地址为 /system/role/list，将 queryParams 作为 URL 参数传递，即最终请求为：

路径：ruoyi-ui/src/api/system/role.js

四、前端开发者工具验证

4.1 请求信息

打开浏览器开发者工具（F12），切换到网络标签，过滤 Fetch/XHR，刷新页面后找到角色管理的分页请求：

• 请求地址包含 pageNum=1&pageSize=10，即前端将分页参数通过 URL 传递给后端
• 请求方法为 GET，状态码 200 OK

4.2 响应信息

切换到预览选项卡，查看后端返回的数据：

• total: 2：后端返回总条数，前端 this.total = response.total 将其赋值，分页组件据此计算总页数
• rows：当前页的实际数据列表
• code: 200，msg: "查询成功"

五、后端源码分析

路径：ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysRoleController.java

• startPage()：读取前端传来的 pageNum 和 pageSize 参数，通过 PageHelper 设置分页拦截
• roleService.selectRoleList(role)：执行实际的数据库查询
• getDataTable(list)：将查询结果封装为包含 total 和 rows 的标准响应体返回给前端

六、后端Log分析

在 IDEA 控制台可以看到，触发一次角色列表请求时，MyBatis 实际执行了两条 SQL：

实际只查询当前页的数据，LIMIT 10 表示取前10条，对应 pageNum=1&pageSize=10。

源码中 selectRoleList 对应的 XML 里并没有写 LIMIT，但 MyBatis 通过 PageHelper 插件在运行时自动拦截并修改了 SQL，加上了 LIMIT 子句，这就是分页的底层原理。

七、总结

RuoYi 框架将分页逻辑高度封装，前端只需使用 <pagination> 组件，后端只需调用 startPage() 和 getDataTable()，即可实现完整的分页功能，开发效率很高。