死链检测工具：功能开关导致页面变化时怎样记录版本状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /149b3467a650.html
📄
死链检测工具：功能开关导致页面变化时怎样记录版本状态
当页面内容由功能开关控制时，死链检测工具抓到的结果只代表抓取那一刻开关所处的状态。要记录可复查的版本状态，关键不是把每次扫描结果都存下来，而是把开关配置快照与当次扫描结果绑定成一条记录。如果开关状态无法在扫描时固定，那么检测结果只能当作参考，不能作为修复依据。
先判断开关是静态配置还是运行时下发
两种条件对应两种记录方式，选错会让版本记录失去意义。
- 静态配置型开关：开关值写在配置文件或构建产物里，同一版本部署后对所有请求表现一致。这种情况下，扫描结果天然对应一个确定的版本，只需记录部署版本号或构建哈希即可。
- 运行时下发型开关：开关值由配置中心、灰度规则或用户分群实时决定，同一时刻不同请求可能拿到不同结果。这种情况下，单次扫描结果无法代表整个版本，必须额外记录扫描时命中的开关组合。
判断依据很简单：用两个不同的请求身份（例如带不同分群标识）访问同一页面，如果返回的链接集合不同，就属于运行时下发型。此时若只记录版本号，后续复现时很可能得到完全不同的结果。
运行时下发型开关的记录动作
对这类开关，扫描前需要先固定一个观测口径，再把口径写进记录。具体动作如下：
- 确定本次扫描使用的分群标识或灰度条件，并把它作为记录的一部分。
- 在扫描开始和结束时各读取一次开关配置，确认扫描期间配置未发生变更。
- 把扫描结果、分群标识、两次配置读取的时间戳写进同一条记录。
这样做的结果是：当后续有人质疑某条死链是否真实存在时，可以按记录中的分群标识重新发起请求，验证当时是否确实返回了该链接。如果两次配置读取不一致，说明扫描期间开关发生了漂移，这条记录应标记为不可用，需要重新扫描，而不是直接进入修复流程。
静态配置型开关的记录可以更轻
如果确认开关只在部署时变化，记录可以简化为版本标识加扫描时间。此时不必记录分群条件，因为同一版本对所有请求表现一致。但要注意一个例外：如果页面链接依赖外部接口返回的数据，而该接口本身受运行时开关控制，那么静态配置的判断就不成立，仍应按运行时下发型处理。
另一个例外是缓存。即使开关是静态的，CDN 或应用层缓存也可能让部分节点返回旧版本页面。判断方法是：在扫描记录中额外标注请求命中的缓存节点或响应头中的缓存状态。如果同一版本在不同节点返回不同链接集合，说明缓存层引入了额外变量，版本记录需要把缓存状态一并纳入。
假设示例：一次开关漂移如何影响判断
假设某页面在开关 A 开启时输出链接 /old-path，关闭时输出 /new-path。某次扫描在开关 A 开启状态下抓到 /old-path 返回 404，于是把它记为死链。但修复人员复查时开关 A 已关闭，页面只输出 /new-path，无法复现该死链，于是误判为工具误报。
如果扫描记录中写明了「分群标识 X，开关 A 开启，扫描前后配置一致」，修复人员就能按同样条件复现，确认 /old-path 在开关 A 开启时确实是死链，进而决定是修复该路径还是调整开关逻辑。这个例子的数字和路径均为假设，仅用于说明记录口径如何改变下一步动作。
把版本状态写进检测流程的落点
记录版本状态不是额外负担，而是决定检测结果能否被采信的前提。可执行的做法是：在死链检测工具的扫描配置中增加一个必填字段，用于填写本次扫描的开关口径；扫描结束后，把口径、配置读取时间戳和结果一起归档。归档记录中若缺少开关口径，该条结果不进入修复队列，只作为观察项保留。
这样处理之后，团队面对开关导致的页面变化时，能够区分「真实死链」和「开关切换产生的临时路径」，避免把版本差异当成链接故障反复修复。对于确实需要长期监控的路径，应把开关条件固定为独立扫描任务，而不是依赖默认口径的周期性扫描。
