做硬件维护的时候，经常要查设备日志、传感器数据或者远程监控信息。这些数据大多通过接口以 JSON 格式返回。当数据量一大，比如上千条温度记录或设备状态变更，直接拉取全部内容不仅慢，还容易卡住前端页面。这时候就得用上 JSON 数据分页查询。
为啥要分页？
想象一下，你在一个机房巡检，手上的平板要加载过去一周每台服务器的运行状态。如果一口气把所有 JSON 数据全读进来，网络延迟高不说，内存可能直接爆掉。而通过分页，每次只拿第一页 20 条，翻页再加载下一批，体验就顺滑多了。
怎么实现分页查询？
大多数 API 接口都会支持分页参数，常见的就是 page 和 size，或者 offset 和 limit。比如请求某设备的历史报警记录：
GET /api/device/alarms?page=1&size=10后端收到请求后，会从数据库里取出对应页的数据，封装成 JSON 返回：
{
"data": [
{"id": 1, "device": "Server-A", "alarm": "CPU Overheat", "time": "2024-03-15T10:23:00"},
{"id": 2, "device": "Switch-03", "alarm": "Port Error", "time": "2024-03-15T10:25:12"}
],
"page": 1,
"size": 10,
"total": 136
}前端拿到这个结构，就能知道当前是第几页、总共多少条、要不要显示“加载更多”按钮。
实战场景：查看温湿度传感器历史数据
假设你在排查一个机柜频繁重启的问题，怀疑是环境温度波动大。现场有传感器每五分钟记录一次数据，一天就有 288 条。你想看三天前的数据，直接请求：
GET /api/sensors/temp-history?date=2024-03-12&offset=0&limit=50第一次拿到前 50 条，发现下午两点开始异常，那就继续查第二页：
GET /api/sensors/temp-history?date=2024-03-12&offset=50&limit=50这样一点点定位时间点，比下载完整 CSV 再打开 Excel 快得多，也更适合集成到运维工具里。
小技巧：别忘了处理边界情况
有时候请求的页数超过实际数据范围，后端应该返回空数组而不是报错。另外，total 字段很重要，它让客户端知道还有没有下一页。如果某次请求 total 是 0，说明压根没数据，可能是设备离线或者时间范围错了，得提醒用户检查参数。
在写自动化脚本时，也可以用循环加递增 offset 的方式批量拉取全部记录，但要注意频率，避免对硬件网关造成压力。