死链检查怎样确认配置实际生效
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /990702871117.html
📄
死链检查怎样确认配置实际生效
确认死链检查配置实际生效，不能只看后台开关是否打开，而要用同一批已知死链和正常链接做对照测试，观察扫描结果、告警记录和处理动作是否与配置一致。如果配置声称“发现404就记录并通知”，但测试链接返回404后既没有记录也没有通知，就说明配置没有生效或没有覆盖到该范围。
先明确配置生效的交付结果
死链检查的配置通常包含扫描范围、判定规则、通知方式、处理动作和执行频率。确认生效，就是确认这些设定在真实请求中产生了可观察的结果。可以从交付结果倒推：一次扫描结束后，应该得到一份死链清单，清单里的链接状态码与配置规则匹配，通知按设定发出，需要处理的链接进入对应流程。
如果只看到“任务已启动”或“配置已保存”，不能作为生效证据。保存成功只说明配置被接受，不等于扫描器真的按它执行。
用一组对照链接做实际验证
准备一组测试链接，覆盖配置中的关键分支。以下示例均为假设，用于说明方法：
- 一个确定返回404的站内链接，用来验证死链能否被发现。
- 一个确定返回200的正常链接，用来验证正常链接不会被误报。
- 一个返回301跳转到有效页面的链接，用来验证重定向是否按配置处理。
- 一个被robots.txt禁止抓取的链接，用来验证抓取限制是否影响检查结果。
把这组链接放入扫描范围，运行一次检查，然后核对输出。判断标准是：404链接应出现在死链结果中；200链接不应出现；301链接的处理方式应与配置说明一致；被禁止抓取的链接如果未被扫描，应能在日志或结果说明中找到对应原因。任何一项与预期不符，都要回到配置项逐条排查。
检查配置覆盖范围与执行记录
配置生效的另一个证据是覆盖范围正确。常见问题是配置只对某个目录生效，而测试链接放在另一个目录；或者通知只发给某个渠道，而测试时没有查看该渠道。排查时先确认扫描入口、路径规则、排除规则和通知目标是否与测试对象匹配。
执行记录比配置页面更能说明问题。查看最近一次扫描的开始时间、结束时间、扫描链接数量、发现死链数量和通知发送记录。如果扫描数量为零，或扫描时间与配置频率不符，说明任务没有按预期运行。如果扫描数量正常但死链数量与对照测试不符，说明判定规则或结果过滤有问题。
区分可能原因与已定位原因
测试失败时，不要直接断定是配置没生效。可能原因包括：配置保存后未重新加载、扫描任务未到执行时间、测试链接被缓存、通知渠道被屏蔽、权限不足导致部分范围未扫描。已经定位的原因则需要证据，例如日志明确显示“跳过该路径”，或通知记录显示“发送失败”。
把现象和解释分开记录：现象是“404测试链接未出现在结果中”，可能原因是“该路径被排除规则过滤”，已定位原因是“排除规则中包含该路径”。只有拿到后者，才能确认配置的实际行为。
验收与下一步
验收时，用同一组对照链接重复运行两次，确认结果稳定。然后检查通知是否到达指定接收方，处理动作是否按配置执行。如果全部通过，配置可以视为在当前范围内生效；如果部分通过，保留测试链接和扫描记录，针对未通过的分支调整配置后重新验证。
下一步是建立一份最小验收清单：测试链接、预期结果、实际结果、差异原因。每次修改死链检查配置后，用这份清单跑一遍，避免只凭开关状态判断生效。
