测试死链接，功能开关导致页面变化时怎样记录版本状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /89860bedce56.html
📄
测试死链接，功能开关导致页面变化时怎样记录版本状态
结论先说：如果功能开关会改变链接是否出现、指向哪里，那么版本状态要记录在“开关配置”这一层，而不是只记录页面 HTML。只有当链接集合完全由静态模板决定、开关不影响它时，才可以把页面快照当作唯一依据。下面给出两种做法的适用条件和代价，以及一个会让上述结论失效的反例。
两种记录方式的分界在哪里
第一种做法是页面快照：抓取渲染后的 DOM，保存当时出现的链接列表。它直观，能直接回答“那一刻用户能看到什么”。代价是它把开关状态隐式地写在结果里，一旦开关组合变化，旧快照无法说明某个链接是被删除了，还是只是被开关关掉了。
第二种做法是配置快照：保存开关名、取值、作用范围，以及该取值下链接的生成规则。它更接近变化的原因，代价是需要额外维护一份“开关到链接”的映射，映射本身也会过期。
选择条件可以这样判断：如果同一个页面在不同开关组合下会产生不同链接集合，且这些组合会被反复切换，用配置快照；如果开关只是灰度发布、之后会长期固定为一种状态，用页面快照更省事。两者都做时，页面快照负责证明结果，配置快照负责解释原因，但要注意时间戳必须对齐，否则无法互相印证。
记录时必须包含哪些字段
无论选哪种方式，下面这些字段缺一个都会让后续判断变得含糊：
- 抓取或记录的时间，精确到能区分两次开关变更的先后。
- 开关标识与取值，包括默认值和当前生效值。
- 链接的完整目标地址，以及它在页面中的位置标识。
- 该链接是服务端渲染输出还是客户端脚本插入。
- 记录时使用的请求身份，例如是否携带登录态或特定地区参数。
最后一条常被忽略：同一个地址在未登录和已登录状态下可能返回不同结果，如果记录时没有说明身份，两次快照的差异就无法归因。
一个会让结论失效的反例
前面说“开关影响链接就用配置快照”，但如果开关的取值来自运行时实验分组，而分组规则本身不落盘、每次请求重新计算，那么配置快照记录的只是某一刻的抽样结果，并不能代表其他请求。此时配置快照和页面快照一样，都只是瞬时观测。这种情况下要记录的是分组规则和抽样条件，而不是某一次的具体取值，否则会把随机差异误读成开关变更造成的差异。
另一个容易误判的情形是：某次记录里目标地址全部返回失败，看起来像链接大面积失效。但这个现象也可能来自抓取端网络、目标站点临时限流，或记录脚本自身的超时设置。请求失败本身不能单独证明链接已经失效，需要换一个网络位置或稍后重测来区分。
下一步动作与它带来的影响
先做一个最小验证：挑一个受开关影响的页面，在开关开启和关闭两种状态下各记录一次，比较链接集合的差集。如果差集为空，说明该开关当前不影响链接，可以把这一页从重点监控里降级；如果差集不为空，就把这个开关加入配置快照的必录清单，并在每次开关变更后重新记录一次。
这个动作的结果会直接决定下一步：差集为空时，后续只需定期做页面快照即可；差集不为空时，页面快照必须和配置快照成对保存，单独一份都不足以支撑复查。若发现差异只出现在客户端插入的链接上，还要额外记录脚本版本，因为同一份配置在不同脚本版本下可能生成不同的地址。
把这些字段固定成模板后，每次开关变更都能留下可对照的两份状态，复查时先看配置差异、再看页面差异，判断顺序不会颠倒。
