把“功能开关状态”当作页面版本的一部分来记录,而不是只记URL和HTTP状态码。具体做法是:在每次抓取或修复前后,为受开关影响的URL保存一份带开关快照的清单,字段至少包括URL、开关名、开关值、记录时间、响应状态和内容指纹;当同一URL在不同开关值下返回不同状态或不同正文时,把它标记为“条件性结果”,不并入批量结论。这样做的直接结果是,你能区分“链接真的坏了”和“链接只是在某个开关组合下不可达”,后续动作也不会误删仍然有效的入口。
功能开关改变页面,通常有三种表现:开关关闭时模块不渲染,导致原本存在的内链消失;开关打开时注入新的跳转或规范链接;开关按用户分组灰度,同一URL对不同访客返回不同内容。这三种都会让死链修复工具给出不一致的结果。
判断依据不是“抓取结果变了”,而是“同一开关值下结果是否稳定”。可以取一个样本URL,在固定开关值下连续记录两次,如果两次的状态码和正文指纹一致,说明该开关值下的页面是确定的;再切换开关值重复记录,若结果不同,才把差异归因到开关。若同一开关值下两次结果也不一致,优先怀疑缓存、CDN或会话状态,而不是开关本身。
这一步的实际动作是建立最小对照:一个URL、两个开关值、每个值两次记录。结果会影响下一步——只有确认差异可复现,才值得把该URL纳入版本化清单;不可复现的差异先按缓存问题排查。
普通死链清单只记URL和状态码,遇到开关就会互相覆盖。要改成追加式记录,每次写入新行而不是更新旧行。建议字段如下:
feature_x=on 或 feature_x=off。这样做的结果是,同一URL会出现多行。后续判断“是否死链”时,必须先声明以哪个开关值为准,否则结论无法复核。如果工具只能输出单行结果,就把开关值写进URL的备注字段,或按开关值分文件保存。
个别样本成立,不等于全站成立。开关影响范围可能只覆盖部分模板、部分语言或部分登录状态。扩展前先确认三件事:开关是否只作用于特定路由前缀;开关是否与用户身份绑定;开关是否有默认值且默认值在无Cookie时生效。
假设某站点只在商品详情模板上挂了开关,列表页和帮助页不受影响。此时把详情页的“开关关闭即404”结论套到全站,会误判大量正常页面。合理做法是按模板分组,每组各取一个样本,分别记录开关两态。只有当同一模板下多个样本表现一致,才把该模板整体标记为受开关影响。
如果无法确认开关的默认行为,就先在无Cookie、无登录的干净会话中记录一次,作为基准行。基准行与登录态行的差异,单独归为“身份相关”,不混入开关版本。
版本化记录的价值在于让修复动作有明确前提。对每个受开关影响的URL,按以下顺序处理:
每次修复后,用相同的开关值重新记录一行,对比新旧内容指纹。指纹变化说明修复生效;状态码未变但指纹变了,说明只改了内容没解决可达性,需要继续排查。若修复后状态码恢复但指纹与开关打开时的预期版本不符,说明缓存或模板选择仍有问题,下一步应清理该URL的缓存并复测,而不是直接关闭工单。
抓取量或某状态码数量突然归零,不能单独证明修复正确。它也可能是抓取被限流、开关被临时关闭、或工具只覆盖了部分URL。保留原始记录行,比保留汇总数字更有用。
另外,robots.txt限制抓取不等于可靠的索引移除,站点地图也不保证收录。若开关导致页面在抓取时不可达,先确认是抓取限制还是真实404,再决定是否调整规则。不同搜索引擎对开关渲染和索引的处理需要分别核查,不能用一个平台的表现推断另一个。
最后,把开关状态写进版本记录后,任何一次“死链已修复”的结论都应能回答:在哪个开关值下、哪个时间点、哪个内容指纹。回答不了,就说明记录还不完整,应回到清单补字段,而不是继续扩大修复范围。