接口分页查询怎么设置page和size参数
遇到接口分页数据对不上?本文解析page和size参数的核心设置规则,包括起始索引选择、默认值配置及异常处理,助你避开常见的分页陷阱。
明明传了 page=2 和 size=10,为什么拿到的还是第一页的数据?或者干脆报了个“页码超出范围”的错误?这种让人头大的情况,通常不是代码写错了,而是前后端对“第几页”的理解没对齐。分页看似简单,却是接口联调中最容易踩坑的地方之一。
最优先要确认的,不是数据库查询语句,而是 page 参数的起始索引。这是所有分页问题的根源。有的团队习惯从 0 开始计数(第0页、第1页),有的则坚持从 1 开始(第1页、第2页)。如果前端传 page=1 想要第二页,而后端按从 0 开始计算,结果就会错位。在定义接口文档时,必须明确写出:page 是从 0 还是 1 开始。

从0开始与从1开始的页码映射关系对比
接下来是 size 参数,它控制每页展示多少条数据。这里有两个关键点:默认值和最大值。不要指望调用方每次都传 size,后端必须设一个合理的默认值,比如 10 或 20。同时,为了防止有人恶意传入 size=99999 拖垮数据库,一定要设置上限。通常建议将最大单页数量限制在 100 或 500 以内,超过则强制截断或报错。
在实际编码中,参数的校验逻辑应该放在服务层的最前端。当接收到请求时,先检查 page 是否小于起始值(如 < 0 或 < 1),再检查 size 是否在合法区间(如 1-100)。如果参数非法,直接返回清晰的错误提示,而不是让程序带着错误参数去查数据库,最后返回空列表让用户猜谜。

分页参数接收后的校验处理流程
还有一个容易被忽视的细节是总页数 totalPages 的计算。很多开发者直接用 total / size,这在整除时没问题,但有余数时就会少算一页。正确的做法是使用向上取整函数,例如 Java 中的 (total + size - 1) / size 或 Python 中的 math.ceil(total / size)。确保前端能准确显示“共 X 页”,避免用户翻到最后一页时发现数据没了,或者还能继续点击下一页。

向上取整计算总页数的数学逻辑
最后,考虑一下极端情况:当查询结果为空时,接口应该返回什么?标准的做法是返回一个包含空列表的结构,同时 total 为 0,page 保持当前请求值。不要返回 null 或 404 错误,这会让前端的列表组件渲染崩溃。保持一致的响应结构,比节省那几个字节更重要。

查询结果为空时的标准JSON响应结构
排查分页问题时,按这个顺序走:先看起始索引是否统一,再看 size 是否有默认值和上限,最后检查总数计算是否向上取整。把这三点固化为团队的接口规范,能省去绝大部分因分页导致的联调扯皮。

































