爬虫分页抓取陷阱：游标分页、总量上限与漏采排查

帮助中心关于爬虫爬虫分页抓取陷阱：游标分页、总量上限与漏采排查

作者：山水代理

发布时间： 2026-10-17 08:40:28

阅读量： 12 人次

分页不是"翻到没有下一页为止"

分页抓取看起来是爬虫里最简单的一件事：拿到第一页、解析出下一页链接、循环到没有下一页。但真实项目中的漏采问题，多数出在这个环节——脚本跑完没有报错，数据也落了库，事后核对数量却发现对不上。原因通常不是代码写错，而是分页机制本身的假设在数据持续变化的场景下不成立。本文梳理爬虫分页的常见陷阱，以及怎么把漏采查出来。

一、先认清三种分页形式

1、偏移分页
最常见的形态，通过页码或偏移量加条数定位数据切片。实现简单，但对数据变化非常敏感。

2、游标分页
服务端返回一个不透明的游标，下次请求带上它取后续数据。稳定性明显更好，代价是不能跳页、游标可能有时效性与筛选条件绑定。

3、时间或 ID 区间分页
以前端滚动加载或按时间倒序的列表为代表，实际可以用时间戳或自增 ID 作为游标自行分片，是工程上最可控的一类。

二、偏移分页的四个坑

1、翻页过程中数据在变
这是最经典的一种漏采。列表按时间倒序排列时，如果在你取完第一页之后有新记录插入到顶部，原本第二页的记录会被整体后移一位，翻到第二页时就会跳过一条。页面看起来翻完了，数据却少了一条。

2、深度分页存在上限
出于性能与风控考虑，相当多的接口会限制最大页数或最大偏移量，超过之后返回空列表或错误。此时收集到的数据是一条完整的"假结束"，很容易被当成"已经翻到底"。

3、排序键不唯一，顺序不稳定
如果排序依据只有时间、而同一时间存在多条记录，服务端每次返回的相对顺序可能不同，结果就是一部分记录被重复采集，另一部分始终没有出现。稳定的做法是使用"时间加唯一ID"这类能确定全序的排序键。

4、总数不可信
列表接口返回的总条数经常是估算值或缓存值，与实际逐页取到的数量不一致。把它当作校验依据时，差值不代表一定漏采，但需要区分"估算偏差"和"真的少取"。

三、游标分页的失效条件

游标分页规避了偏移位移的问题，但它有自己的边界：游标通常有有效期，长时间不继续请求会失效；游标与生成它的筛选条件绑定，中途改条件需要重新获取；不能跳页，也就不支持并行分片；部分实现下，请求过于密集会被限速，导致游标中断。使用游标时，把游标与对应的数据切片一起记录下来，是断点续采的前提。

四、漏采怎么查出来

1、用唯一标识去重后计数
先按内容唯一ID去重得到真实条数，再与总量口径比对。这一步也能顺带暴露重复采集的问题——重复和遗漏往往同时存在。

2、按时间窗口分片，逐片核对
不要把整个列表一次翻到底，而是按天或按小时切分成独立分片，每片单独核对条数。分片之后，任何一片异常都能被单独发现，也便于失败重试。

3、检查边界重叠
让相邻分片之间保留一小段重叠区间，重新采集后检查重叠部分是否一致。如果重叠区数据对不上，说明边界处理有问题。

4、与历史快照对比
同一数据源的采集量长期平稳时，某一次突然明显下降，通常不是上游数据少了，而是采集环节出了问题。把每轮采集的条数留存下来做趋势对比，是最省力的兜底手段。

五、几个工程上的稳妥做法

优先选择按时间窗口或 ID 区间分片，而不是按页码翻。让排序键唯一且稳定，避免顺序随机。把每片的进度标识与结果条数一并记录，让任务可以断点续采。对分页接口控制请求节奏，避免因频率过高触发限速，导致游标或会话中断。
这里还有一个容易忽略的点：分页请求数量多、目标集中，对出口的稳定性要求偏高。频繁更换出口地址在分页场景下反而容易打断会话，使用固定入口加自动轮换的方式，或者对同一目标保持一段时间的会话一致，通常比每个请求换一个IP更稳。

总结

分页抓取的漏采，根源往往在于分页机制与数据持续变化之间的冲突：偏移分页会因插入删除发生位移，深度分页有上限，排序键不唯一会造成重复与遗漏，总数也可能只是估算。游标分页更稳定，但有有效期、不能跳页、与筛选条件绑定。要发现漏采，靠的是去重计数、按时间分片核对、边界重叠检查和历史趋势对比这几种交叉验证。工程上最省心的做法是放弃"一次翻到底"，改成按时间窗口分片推进，让每个分片都可核对、可重试。