爬虫控制，小流量灰度为何没暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b04da76b6279.html
📄
爬虫控制，小流量灰度为何没暴露全量发布的例外
结论有条件：灰度能验证规则语法、主要路径和常见User-Agent组合，却无法替你验证“例外集合”。全量发布后暴露的，通常是灰度样本里根本没出现的URL形态、参数组合或抓取来源。一旦例外与已放行路径共享同一段规则，灰度通过反而会强化错误信心。
灰度样本天然过滤掉了低频例外
小流量灰度的本质是抽样，而抽样会优先覆盖高频、结构规整的URL。假设你只对首页、栏目页和最近更新的若干详情页放行，规则写的是允许/product/前缀。灰度期间这些页面全部正常，你会判断规则可用。但全量发布后，带有筛选参数、分页参数或大小写变体的URL开始被拦截，它们同样属于产品路径，却因为低频而没进入样本。
这里的关键证据不是“拦截量上升”，而是拦截对象的URL形态。抓取量或请求量归零，也可能是对方降低了抓取频率、站点响应变慢、或抓取预算被其他路径占用，不能单独证明规则正确。要区分这些解释，需要看日志中被拦截的具体路径和User-Agent，而不是只看总量。
例外往往藏在规则的包含关系里
多数爬虫控制事故不是规则写错，而是规则之间的包含关系没被想清楚。允许/a/的同时禁止/a/private/，如果禁止规则写在允许之前，可能整段/a/都被挡住；如果写在之后，又可能因为匹配顺序不同而失效。灰度只走了/a/下的公开页，自然看不出这个顺序问题。
可核对的证据是一组对照：取一条灰度通过的URL和一条全量后出问题的URL，比较它们是否命中同一条规则、命中的是允许还是禁止、以及规则在文件中的先后位置。若两条URL命中同一规则却结果不同，问题在匹配细节；若命中不同规则，问题在规则覆盖范围。这个区分直接决定下一步是改规则内容还是改规则顺序。
一个反例会让上面的结论失效
如果灰度不是按URL抽样，而是按抓取来源或时间窗口抽样，那么上述“例外没进样本”的解释就不成立。例如你只对某个搜索引擎的爬虫放行，灰度期间该来源表现正常，全量后其他来源仍被拦截——这时的例外不是URL，而是User-Agent或来源IP段。此时继续检查URL规则会浪费时间，应转向核对各来源的匹配条件。
换句话说，先确认灰度到底抽的是什么维度，再判断例外可能落在哪里。抽样维度决定了盲区位置，而不是规则本身决定。
下一步动作：把灰度结论降级为假设
全量发布前，做一次“例外枚举”而不是“再抽一次”。列出规则覆盖范围内所有已知URL形态：带参数的、分页的、大小写不同的、带尾斜杠的、来自不同来源的。对每一种形态各取一条真实URL，用与线上一致的匹配逻辑逐条验证，记录命中结果。
这个动作的结果会直接影响发布决策：如果例外全部落在预期内的禁止范围，可以发布；如果有任何一条落在“本应允许却被拦截”的位置，应先修正规则再全量。灰度通过只说明主路径没问题，不能替代这次枚举。发布后仍需保留一段观察期，按URL形态分组统计被拦截情况，而不是只看总拦截量，否则下一个例外仍会被总量掩盖。
