蜘蛛爬行优化：功能开关导致页面变化时怎样记录版本状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c0aa0d0f3d4c.html
📄
蜘蛛爬行优化：功能开关导致页面变化时怎样记录版本状态
功能开关让同一 URL 在两种状态间切换时，真正需要记录的往往不是“页面变了什么”，而是“爬虫在哪个时间点、以什么开关状态、拿到了哪一版可见内容”。如果只在开关切换后截图留档，样本页可能看起来正常，规模化后却出现例外——这正是本文要解决的具体决策：把版本状态记录在抓取链路的上游，而不是事后补记。
矛盾现象：样本成立，规模化后失效
假设一个商品列表页由开关控制是否渲染价格区间模块。关闭开关时服务端返回精简 HTML，打开时由前端异步注入价格区间。单页手动测试时，关闭状态下的 HTML 里没有价格文本，打开状态下有，两者都能被正确识别，样本成立。
但当开关按用户分组或按地域灰度放量后，同一 URL 对不同爬虫请求可能返回不同分支。此时若仍用“开关是否打开”作为版本标识，就会出现同一标识对应多种可见内容的情况，之前的样本结论无法直接照搬。
两种解释：是开关状态不一致，还是抓取时机不一致
规模化后出现例外，通常有两种解释，需要分开验证。
- 解释一：开关状态本身不一致。开关按用户、地域或实验组分流，爬虫请求命中的分支与人工测试时不同，导致同一 URL 返回不同 HTML。
- 解释二：抓取时机不一致。开关状态相同，但页面在客户端执行脚本后才补全内容，而记录时只保存了初始响应，或只保存了渲染后快照，两者被混在同一份记录里。
这两种解释对应完全不同的处理方向。前者要固定分流口径，后者要固定记录口径。若不先区分，容易把时机问题误判为分流问题，反复调整开关配置却不见收敛。
能区分解释的证据：请求级状态字段
要区分上述两种解释，需要让每条抓取记录带上可对照的请求级字段，而不是只记录页面最终长什么样。建议在日志或抓取记录中同时保留：请求时间、完整 URL、响应状态码、开关状态标识、响应体是否包含目标内容、以及是否经过客户端渲染后二次采集。
关键动作是：为每次抓取写入一个开关状态标识，并在同一批次内固定采集方式（只存初始响应，或只存渲染后快照，二者不混）。执行后，如果同一开关标识下仍出现内容差异，且差异集中在“是否渲染后采集”这一维度，则支持解释二；如果差异集中在开关标识本身，则支持解释一。这个动作的结果直接决定下一步是去收敛分流规则，还是去统一采集口径。
一个注明假设的短例子
假设某列表页开关按地域分流，A 地域关闭、B 地域打开。若记录中 A 地域标识下仍出现价格文本，且这些记录都来自渲染后采集，则说明差异来自采集方式而非分流；此时应统一为同一采集口径再比较，而不是继续改开关。该例子为说明比较方法而设，不代表任何真实站点结果。
记录版本状态时不能直接照搬的边界
把样本页的记录方式推广到全站前，需要确认几个边界。
- 开关若按用户维度分流，爬虫请求通常不带登录态，命中的分支可能与真实用户不同，样本结论不能直接外推。
- 站点地图只描述 URL 与更新信息，不保证收录，也不能反映开关状态；它不能替代版本状态记录。
- robots.txt 的抓取限制不等于可靠的索引移除，用抓取限制来“冻结”某个开关状态并不可靠。
- HTTPS 不保证页面内容安全或排名，与开关状态记录无关，不应作为版本标识的一部分。
- 不同搜索引擎对客户端渲染内容的处理方式需分别核查，不能以某一家的表现推断全部。
当这些边界未被确认时，样本成立不代表规模化后成立。更稳妥的做法是先在受控批次内固定开关标识与采集口径，再逐步扩大范围，每扩大一次都保留可对照的请求级记录。
从记录到决策：什么情况下可以继续推进
当同一开关标识下的内容差异能稳定归因到单一维度（分流或采集时机），且记录中不再出现两种口径混用，才具备把结论外推到更多 URL 的条件。反之，如果差异仍无法归因，应先缩小采集范围，而不是增加开关维度。请求量或抓取量归零并不能单独证明处理正确，它也可能来自分流规则变化、采集失败或记录字段缺失，需要结合请求级状态字段一并判断。
