采集量骤降的归因：先怀疑自己，再怀疑源站

波动诊断最怕的是“结论来得比证据快”。我给自己定的顺序是：先把自己排干净，再谈源站。

01排除顺序

步骤	检查什么	判定依据
一	脚本是否被改动过	按文件 mtime 看，只有日志文件变化就排除
二	入湖环节是否丢数	爬虫侧原始行数与集群侧入湖行数逐日对比，应逐类目相等
三	分页是否被提前截断	日志里检索“达到分页上限”的命中情况
四	解析效率是否下降	每页入库条数是否仍然稳定
五	源站供给是否变化	用归档 HTML 重放，比对页数与同页号的商品链接数

前四步都是否证：证明“我这里没坏”。只有它们都排掉，第五步才有意义。

第五步是这套流程里唯一能正面回答问题的：因为原始页面留了档，我可以对历史 HTML 离线重放，把“页数”和“每个页号上出现的商品链接数”逐日画出来。看到的现象是两类同时发生——部分类目尾部页的有效商品减少，部分类目页数变多。这种组合只有源站改版能解释，脚本 bug 造不出这种模式。

结论：**采集如实反映了源站供给的变化。**这是一个“没坏”的结论，但只有走完排除顺序才敢说。

有过一次相反的经历，值得单独写。某天产出骤降，我判断“触发了反爬”，因为时间点和访问强度对得上，于是先去调速率、加冷却，链路照旧不对。回头细看才发现是解析器在一个新模板分支上取错了节点——兜底页判定被绕过，产出空但任务成功。

教训不是“不要怀疑风控”，而是：

排查时发现日报是在其中一个源跑完之前生成的，所以日报里的条数和耗时实为单源口径，另一个源从未进过那份统计。

这类问题的讨厌之处在于它不影响数据、只影响你对数据的信任。修法是让日报的生成时间对齐“全部源结束”，或者在日报里显式标注当前包含哪些源。报表的统计口径必须写死在报表里，否则它会在某天悄悄变成另一种东西。

参数补采源（详情页那一类）不在日更调度里，它是慢变维：某天源端没有新增是完全正常的。

消费侧的正确姿势是“按 SKU 取最新一份快照”，读全部分区后去重取最新，而不是断言“每天都该有数据”。我一开始把按日齐备性检查套在它上面，于是链路每天报缺失。

任何“应该有但为空”的告警，先问它的数据契约里有没有“每天必有”这一条。没有的话，这个告警就是噪声，而且会把真信号埋掉。

波动归因最后沉淀成三件东西：一套排除顺序、一次离线重放的能力、以及“口径要显式写在报表里”的习惯。第一件靠流程，第二件靠留档，第三件靠自觉。