接口分页查询怎么设置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 是否有默认值和上限，最后检查总数计算是否向上取整。把这三点固化为团队的接口规范，能省去绝大部分因分页导致的联调扯皮。