淘宝指数查询自动导出遗漏分页时怎样检查完整性
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cea45bce8af5.html
📄
淘宝指数查询自动导出遗漏分页时怎样检查完整性
先给结论：自动导出漏掉分页，多数时候不是“最后一页没抓到”，而是导出任务在翻页过程中提前判定结束，或者分页游标被重复、跳过。检查完整性的关键动作，是拿导出结果与一份独立获取的分页清单做逐页比对，而不是只看总行数。总行数对得上，仍可能中间缺页、尾页重复，所以必须落到页码或时间切片这一层。
为什么总行数看起来正常，分页却可能缺失
一个常见的矛盾现象是：导出文件的行数和大致预期接近，但抽样核对时发现某几个时间段的数据明显偏少。这时有两种成立的解释。
- 解释一：翻页逻辑提前终止。导出程序在某一页返回空结果、返回条数少于页大小，或遇到一次请求失败后，就认为已经到底，于是停止翻页。后面即使还有数据，也不会再请求。
- 解释二：分页边界重复或跳过。程序用页码翻页时，如果数据在导出过程中发生新增或删除，后续页的内容会整体前移或后移，导致一部分记录被跳过，另一部分被重复抓取。重复行被去重后，总行数看起来仍然合理。
这两种原因的修复方向完全不同：前者要改终止条件，后者要改翻页方式。所以先区分原因，再动手补数据。
用哪一组证据区分这两种解释
能区分它们的证据，是“每一页的抓取记录”，而不是最终合并后的文件。让导出程序在运行时输出一份日志，每请求一页就记录：请求的页码或游标、返回条数、本页首条和末条记录的某个稳定标识（例如商品ID或时间戳）。
拿到日志后这样判断：
- 如果日志显示程序在某个页码后就再无请求，而通过其他方式确认该页码之后仍有数据，属于解释一，终止条件有问题。
- 如果日志显示页码连续请求到了末尾，但相邻两页的首末标识出现重叠或断层，属于解释二，翻页边界不稳定。
- 如果日志本身缺页（页码不连续），说明是请求调度或重试逻辑丢了任务，这是第三种情况，同样要单独处理。
假设一个例子：某次导出共请求了 40 页，每页 100 条，合并去重后得到 3860 行。表面看接近 4000，似乎只差一点。但检查日志发现第 17 页返回 0 条后程序就停了，而第 18 页其实有数据。这里总行数的“接近”纯属巧合，真正的问题是提前终止。
完整性检查该比对什么基准
要判断有没有漏，必须有一个独立于导出程序的分页基准。可行的做法是先单独跑一次“只取分页信息”的轻量查询，把总页数、每页条数、末页条数记下来，再和导出日志逐页对照。基准和导出不要共用同一套翻页代码，否则同一个 bug 会在两边同时出现，比对就失去意义。
对照时重点看三处：
- 页数是否一致。导出实际请求的页数，应等于基准页数。少于基准，就是漏页。
- 每页条数是否符合预期。除末页外，各页条数应等于页大小。某页明显偏少，可能是该页被截断。
- 相邻页的标识是否衔接。上一页末条与下一页首条之间，按排序字段应当连续，不应出现无法解释的跳跃或完全相同的重复。
发现遗漏后，先做什么再决定下一步
不要急着重跑整个导出。先做一个小范围补抓：只针对日志中可疑的那几页，单独请求并保存，然后与主文件按稳定标识合并去重。合并后再次统计总行数和各时间切片的条数。
这个动作的结果会直接决定下一步：如果补抓后各页标识衔接正常、切片分布也合理，说明只是翻页终止或边界问题，修好终止条件和翻页方式即可；如果补抓时仍然出现同样的缺页，说明问题出在查询条件本身（例如筛选条件把部分数据排除了），这时改导出程序没有用，要先核对查询口径。在查询口径未确认前，不要用总行数归零或抓取量下降来证明处理正确，因为筛选条件变化、数据本身更新、请求被限流，都能产生同样的现象。
把完整性检查固定成可复用的动作
每次自动导出后，按顺序做三件事：保存导出日志、生成独立的分页基准、逐页比对页数与标识衔接。只有三步都通过，才把文件标记为完整。任何一步不通过，先定位是终止条件、翻页边界还是查询口径，再决定补抓范围。这样即使换工具或换查询对象，检查方法本身仍然成立；具体工具的分页上限、导出条数限制等信息，需要以实际使用时看到的为准。
