这类问题我又碰上了一次。自建索引报表脚本调站长平台的索引量接口 每页 1000 条 循环条件写 page 小于等于 1 分页参数却没自增 实际只取了第一页 报表长期比后台少 3 万条 团队一直以为是接口延迟
第一反应是「脚本没有对条数做断言 少了也不报错」，验证下来不成立。
排查方向其实有限，先把可能性排一排。分页参数在循环里没有自增 每次都请求第一页；接口返回的 total 字段没有参与校验；本地缓存把第一次结果存了下来 后续读同一份。
动手时先看脚本实际请求了几次
grep -c 'GET /index' fetch.log修正分页自增并按 total 校验
while page * size < total: page += 1去掉本地缓存后重跑一次全量
python fetch_index.py --no-cache --full剩下的就是对比接口总数与报表条数
python -c "print(len(rows), total)"怎么算真的好了，看的是同一批现象。报表条数与接口 total 一致 与后台展示的索引量误差在 1% 以内 分页请求次数等于页数。
任何带分页的接口都要用 total 做一次断言 少一页的报表比没有报表更难发现。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。