爬虫日志分析，小流量灰度为何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d4acdafab94.html
📄
爬虫日志分析，小流量灰度为何暴露全量发布的例外
因为灰度样本只覆盖了“被选中的那部分请求”，而全量发布改变的是请求的整体构成：入口分布、参数组合、缓存命中、跳转链路都会变。灰度里没出现的路径，不等于全量里不会出现；灰度里正常的路径，也可能因为量级上升而触发另一套处理逻辑。所以爬虫日志分析在灰度阶段的任务不是确认“没问题”，而是找出哪些结论只在灰度条件下成立。
先看一个常见矛盾：灰度干净，全量却冒出陌生URL
假设你只对站内某个栏目做了灰度，日志里抓取该栏目的请求状态正常，返回码集中，耗时稳定。全量上线后，日志里却出现了灰度期间从未见过的URL形态，比如带额外查询参数的列表页、被拼接出来的筛选页、或是从旧模板继承下来的分页地址。直觉会认为“灰度验证过了，全量不该出问题”，但事实相反。
这不是灰度失效，而是灰度选择本身造成了盲区。灰度通常按流量比例、用户分群或栏目切分，被选中的样本天然偏向某些入口。全量发布后，原来被挡在外面的入口开始贡献请求，爬虫的发现路径随之改变。
两种解释：是爬虫行为变了，还是站点暴露面变了
解释一：爬虫发现了灰度期不存在的链接
灰度期页面可能只对部分访问者输出某些链接，或者某些链接只在特定参数下才渲染。全量后这些链接对所有请求可见，爬虫顺着新链接进入未预期的路径。这种情况下，陌生URL的源头在站内，日志里的Referer或发现路径能指向具体页面。
解释二：站点自身在全量后产生了新的URL组合
另一种可能是发布动作本身改变了URL生成规则，比如筛选条件从白名单变成透传、分页参数被重新拼接、或某个中间层开始把内部标识写进链接。此时陌生URL不是被“发现”的，而是被“制造”的，和爬虫无关。
两种解释都会表现为“灰度没有、全量出现”，但处理方向完全不同：前者要收敛站内链接暴露，后者要修生成逻辑。
用可核对的证据区分这两种解释
关键证据是陌生URL第一次出现时的那条日志上下文，而不是它的数量。可以从三个角度核对：
- 发现来源：该请求的Referer指向站内哪个页面？如果指向一个灰度期不可见的页面，偏向解释一；如果Referer为空或指向自身，偏向解释二。
- 参数来源：把陌生URL的参数和站点模板、路由配置对照。参数值如果来自站点内部字段命名体系，偏向解释二；如果是外部拼接的常见筛选词，偏向解释一。
- 出现时间与发布动作的关系：如果陌生URL在发布完成后立即集中出现，且只出现在新版本才有的路径前缀下，更支持解释二；如果延迟出现、逐步增多，更支持解释一。
这里要提醒一点：请求量归零或某项统计突然消失，不能单独证明处理正确。它也可能来自缓存切换、CDN回源变化、抓取预算临时转移，或日志采集本身的断点。要先用上述上下文证据排除这些解释，再决定下一步。
一个假设例子：灰度只放行一个栏目会漏掉什么
假设某站点灰度只放行“帮助中心”栏目，全量后放开“商品列表”。灰度日志里帮助中心的抓取正常，于是团队认为发布安全。全量后商品列表的筛选参数被爬虫大量组合，产生了灰度期不存在的URL。此时如果只看“灰度通过”这个结论，就会误判为爬虫异常；如果回看日志里第一条筛选URL的Referer和参数来源，就能判断是列表页链接暴露问题，而不是爬虫突然改变行为。
这个例子的数字只是说明比较方法：灰度覆盖的入口越窄，全量后新增的请求构成差异越大，越需要把“灰度结论”限定在灰度覆盖的范围内。
灰度后该做的一个实际动作
在全量发布后的第一轮日志里，按“灰度期是否出现过”给URL分组，而不是按返回码分组。对只在全量后出现的URL，逐条记录它的Referer、参数来源和首次出现时间。这个动作的结果会直接决定下一步：如果陌生URL集中在少数几个站内入口，优先收敛这些入口的链接输出；如果分散且参数来自站点自身生成逻辑，优先回查发布改动中的URL拼接部分。
同时要接受一个前提：robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录。灰度与全量的对照只能帮你定位例外来源，不能替代对具体URL处理方式的判断。不同搜索引擎对同一路径的支持情况需要分别核查，不能把一次日志结论直接套用到所有抓取方。
把灰度当作一次受控采样，而不是一次缩小版的全量验证，才能解释为什么小流量阶段干净、全量阶段却冒出例外。
