百度蜘蛛抓取：小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9836f76a4d2e.html
📄
百度蜘蛛抓取：小流量灰度如何暴露全量发布的例外
小流量灰度之所以能暴露全量发布的问题，不是因为灰度样本更“干净”，而是因为它把同一批URL在两种抓取条件下做了对照：灰度期间只放开部分入口、部分目录或部分参数，全量后入口和参数组合突然增加。例外通常出现在灰度没覆盖到的组合里，而不是灰度样本本身出错。
先分清灰度的两种条件：入口受限与参数受限
入口受限指灰度只提交部分栏目、部分列表页或部分站点地图文件，全量时再打开其余入口。参数受限指灰度只允许不带参数或只带一种参数的URL被抓取，全量时放开筛选、排序、分页等参数组合。两种条件下，百度蜘蛛抓取的行为差异完全不同。
- 入口受限：灰度能验证“新入口是否可被抓到”，但验证不了“旧入口与新入口同时存在时，抓取预算会怎么分配”。全量后常见例外是旧列表页被新入口挤掉，抓取量没有按入口数量等比例增加。
- 参数受限：灰度能验证“单个参数URL能否返回正确内容”，但验证不了“多参数叠加后是否产生大量近似重复”。全量后常见例外是参数组合爆炸，抓取请求集中在少数模板上，真正需要更新的详情页反而变少。
判断该选哪种灰度，依据是本次发布改变了什么。如果发布只增加新栏目，选入口受限；如果发布改动了筛选、排序或分页逻辑，选参数受限。两者都改时，不要用一次灰度同时验证，否则例外出现后无法归因。
灰度期间要记录可区分的证据，而不是只看抓取总量
抓取总量上升或下降，不能单独证明灰度处理正确。它至少还有三种合理解释：服务器响应变慢导致抓取自然减少、站点地图更新触发一轮集中抓取、外部链接或站内入口变化改变了爬虫到达路径。因此灰度期间至少要分开记录以下证据。
- 按目录或模板分组的抓取请求数，而不是全站总数。这样能看出增长来自新入口还是旧入口。
- 同一模板下“返回200且内容有更新”的URL占比。抓取多但内容没更新，说明抓取被浪费在无变化页面上。
- 带参数URL与不带参数URL的抓取比例。参数受限灰度中，这个比例是判断全量后是否失控的关键。
- 服务器日志中百度蜘蛛的响应码分布。大量5xx或超时会掩盖真实的抓取意愿变化。
一个假设例子：灰度只放开A目录，日志显示A目录抓取从每天100次升到300次，同时B目录从200次降到150次。如果只看全站总量，会得出“抓取增加50次”的结论；分开看才发现抓取预算在目录间发生了转移。全量后若B目录入口也打开，这种转移可能反转，也可能加剧，取决于哪个目录的更新频率更高。
全量发布后，先验证例外是否落在灰度未覆盖的组合上
全量后出现抓取异常时，第一步不是回退，而是确认异常URL是否属于灰度未覆盖的入口或参数组合。具体动作是：从日志中筛出抓取量下降或报错的URL，按“是否在灰度名单内”“是否带参数”“属于哪个模板”三个维度分组。
如果异常集中在灰度名单外的URL，说明灰度边界设置过窄，问题出在覆盖范围，而不是发布逻辑本身。此时下一步是补做一次针对该组合的小范围验证，而不是直接全量回退。如果异常同时出现在灰度名单内的URL上，说明发布逻辑本身有问题，回退才有依据。
这个动作的结果会直接决定下一步：覆盖范围问题只需扩大灰度边界重新验证；逻辑问题需要先修复再重新灰度。两者混在一起处理，会导致修复后仍然无法判断问题是否解决。
哪些情况下灰度结论不能直接照搬到全量
灰度样本成立但全量出现例外，通常有三个边界不能直接照搬。
- 抓取预算边界：灰度期间参与竞争的URL少，预算充足；全量后URL数量增加，同一批URL分到的抓取次数可能下降。灰度中“每个URL都被抓到”不能推导出全量后仍然如此。
- 重复内容边界：灰度只放开一种参数时，页面之间差异明显；全量放开多种参数后，可能产生大量内容近似但URL不同的页面。灰度中“内容可区分”不能推导出全量后仍可区分。
- 入口权重边界：灰度只提交新入口时，新入口是唯一新增路径；全量后新旧入口并存，爬虫可能优先走旧路径。灰度中“新入口被抓取”不能推导出全量后新入口仍被优先抓取。
此外，robots.txt中的抓取限制不等于可靠的索引移除，站点地图提交也不保证收录。灰度期间如果依赖这两项来控制抓取范围，全量后需要重新核查实际生效情况，而不是假定它们仍然按预期工作。
把灰度结论转成全量决策的最小检查
在全量发布前，用以下三个问题判断灰度结论是否可用：异常URL是否全部落在灰度覆盖范围内；抓取预算在灰度期间是否已经接近饱和；参数组合数量在全量后是否会成倍增加。任一问题的答案是否定的，灰度结论就只能作为参考，不能作为全量放行的依据。
全量发布后，先按模板和参数分组对比抓取分布，再决定是扩大验证范围还是回退发布逻辑。这样做的结果是，例外出现时你能知道它属于覆盖不足还是逻辑错误，而不是在两种可能之间反复猜测。
