鄂奎阿1. 为什么那么多人误以为若依分页“只支持GET”
我最早接触若依框架（RuoYi）的时候，也犯过同样的“思维定式”：分页查询嘛，无非就是把页码和每页条数拼到 URL 上，以 GET 请求的方式发给后端。这种习惯来自若依官方文档里大量以表格查询为主的示例，比如用户管理、角色管理、菜单管理这些页面，列表数据的加载几乎清一色是 GET 请求，参数直接暴露在地址栏上。
但是真实项目里需求是五花八门的。我这边的系统里有一个“订单流水查询”页面，查询条件特别多：时间范围、订单号、客户名称、商品编码、渠道来源、支付状态、物流单号……十几个筛选字段全部加在一起，URL 能拼出很长一串。更麻烦的是部分查询场景涉及敏感信息，比如客户手机号、身份证后四位，这些东西放到 URL 上的话，会留在浏览器历史记录、Nginx 访问日志、网关日志里，从安全角度来说非常不友好。后来我改成了 POST 提交，却发现若依的通用分页好像不起作用。一时间真的以为这个框架的 PageHelper 只认 GET。
不是若依不支持 POST，而是我们没有真正理解若依分页的底层机制。打个比方，若依的分页就像一把锁，很多人只见过用钥匙开锁（GET 请求中的 pageNum/pageSize 参数），就以为这把锁只能用钥匙打开，实际上只要参数配对，门禁卡、指纹都可以解锁。HTTP 方法只是传输方式的差别，分页参数的解析在框架内部其实是和请求方式解耦的。
要摆脱这个误区，必须从若依分页的完整链路看起。下面我拆解一下相关的核心代码和参数流转过程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 源码视角：若依分页的“发动机”在参数解析而非请求方式
2.1 TableDataInfo 与分页参数的默认绑定过程
若依后端的分页入口，核心是一个 BaseController 类，里面有一个 startPage() 方法，几乎所有表格查询接口都会调用它。这个方法做的事情很纯粹，就是把前端传上来的 pageNum 和 pageSize 读取出来，交给 PageHelper 去处理。
java复制protected void startPage() {
PageDomain pageDomain = TableSupport.buildPageRequest();
Integer pageNum = pageDomain.getPageNum();
Integer pageSize = pageDomain.getPageSize();
String orderBy = SqlUtil.escapeOrderBySql(pageDomain.getOrderBy());
Boolean reasonable = pageDomain.getReasonable();
PageHelper.startPage(pageNum, pageSize, orderBy).setReasonable(reasonable);
}
关键就在 TableSupport.buildPageRequest() 这个静态方法。它内部用了 ServletUtils.getParameter() 从 request 里取参数。ServletUtils 对 HTTP 请求的读取是没有区分 GET 还是 POST 的，Tomcat 容器把请求参数统一封装成一个参数表，不管是 query string 里的键值对，还是请求体里以 application/x-www-form-urlencoded 格式提交的键值对，在 Servlet 层面都放进了同一个 parameter map。也就是说，只要 POST 请求的 body 里带了 pageNum=1&pageSize=10 这种 URL 编码的键值对，request.getParameter("pageNum") 就能取到值。
若依源码里对请求方式确实有判断，但那个判断是用来处理“排序字段”的，而不是判断分页是否被允许。在 TableSupport.buildPageRequest() 中，它会调用 SqlUtil.filterKeyword() 清理排序相关关键字，同时处理 isAsc 这个排序方向字段。这些参数同样是从 request 的 parameter 里读的，无论 GET 还是 POST，读取路径完全一样。
2.2 PageHelper 的分页上下文生命周期
当你调用 startPage() 之后，PageHelper 会把分页参数存储在 ThreadLocal 中。这里有个很重要的机制需要理解：PageHelper 不是通过方法签名、注解或者请求类型来感知分页的，它是靠“下一次执行的 MyBatis 查询语句”来触发拦截器。
java复制PageHelper.startPage(pageNum, pageSize);
// 下一个执行的查询会被自动分页
List<YourEntity> list = yourMapper.selectYourList(query);
startPage() 和紧接着的 Mapper 查询方法之间，不需要有任何代码层面的绑定关系。只要这两步在同一个线程内执行，PageHelper 就认为你要对下一次查询做分页。所以理论上讲，无论 GET 还是 POST，只要请求进入了后端同一个线程，并在调用 Mapper 方法之前执行了 startPage()，分页一定生效。
很多人遇到的“POST 分页失效”问题，其实根本原因在自己的业务代码层面。最常见的有两种情况：第一，Controller 方法里压根没有调用 startPage()，而是自己在 Service 里直接 new 了一个分页对