爬虫控制：一个修复引发另一类异常时怎样拆开依赖链
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8df8130e1531.html
📄
爬虫控制：一个修复引发另一类异常时怎样拆开依赖链
先给有条件的结论：如果修复只改了一条规则，却让另一类请求开始异常，优先怀疑的不是这条规则本身，而是与它共享匹配顺序、路径前缀或状态码处理的上游环节。把依赖链拆成“谁先决定、谁后继承、谁最终执行”三段，再逐段替换验证，通常比回滚整条规则更快定位。这个结论只在你能拿到修复前后的请求样本时成立；如果样本全是正常流量、没有保留被拒或被重定向的原始响应，拆链会退化成猜测。
先确认异常是不是同一类请求换了表现
修复后出现的“另一类异常”，有时并不是新问题，而是原来被掩盖的请求换了状态码。例如原本被 Disallow 挡住的路径，修复后放行，却因为上游重写规则把它导向了另一个目录，于是表现为大量 404 或重复内容。判断方法是对比修复前后同一批 URL 的响应码分布，而不是只看总量。
可区分的原因至少有三组：
- 匹配顺序变了：新规则插在前面，抢先命中了本该由后面规则处理的路径。
- 前缀重叠：两条规则覆盖同一段路径，谁生效取决于书写顺序而非意图。
- 状态码继承：上游返回 301 或 403，下游规则只是被动转发，异常根因不在爬虫控制层。
如果这三组都无法解释，才考虑是外部抓取行为变化，而不是你的修复引入的。
把依赖链拆成三段，而不是一条规则
依赖链的拆法是按决策发生的先后顺序切，不是按文件切。第一段是入口判定：请求先经过哪一层，是服务器重写、CDN 规则还是 robots 匹配。第二段是继承层：后面的规则是否复用了前一段的路径、参数或状态。第三段是执行层：最终返回什么给抓取方。
一个假设例子：某站点修复了被误拦的产品页，放行后却发现分页参数页开始返回 200 空内容。拆链后发现，入口层放行了 /product/ 前缀，继承层把 ?page= 也一并纳入，执行层没有对应内容却仍返回 200。这里真正的断点在继承层的前缀粒度，而不在放行动作本身。
拆链时至少保留一份修复前的原始响应，否则你无法区分“新异常”和“旧异常被暴露”。
让结论失效的反例：样本成立不等于规模成立
最常见的失效边界是：你在少量 URL 上验证通过，就认为整条链已修好。个别样本成立但规模化后出现例外，通常来自三类边界——参数组合、大小写与编码差异、以及不同抓取方的匹配行为差异。robots.txt 的抓取限制不等于可靠的索引移除，同样，样本放行也不等于全量放行。
另一个反例是站点地图。修复后你更新了站点地图并观察到抓取量上升，但这不能单独证明修复正确：抓取量上升还可能来自抓取预算重新分配、其他路径被放开，或抓取方本身的调度变化。站点地图不保证收录，抓取量归零也不能单独证明规则生效。
不同搜索引擎对同一写法的支持情况须分别核查，不能把在一个抓取方上验证通过的结果直接套到另一个上。
下一步动作：用最小替换验证断点
确认依赖链后，不要整条回滚，而是做一次最小替换：只改继承层的一个粒度，例如把前缀匹配收窄到具体目录，或把参数页单独排除。动作执行后，重新抓取同一批 URL，比较响应码和内容长度是否与修复前一致。
如果替换后异常消失，说明断点在继承层，下一步应把该粒度写成显式规则并记录顺序；如果异常仍在，说明断点在上游入口层，需要回到第一段重新取样。这个动作的价值在于把“哪一层出错”变成可证伪的判断，而不是继续在整条规则上反复试。
记录每一步的改动位置和对应响应，是让下一次修复不再引发另一类异常的前提。
