死链检查方法：怎样确认配置实际生效
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2954392f0131.html
📄
死链检查方法：怎样确认配置实际生效
确认死链检查配置实际生效，不能只看配置文件写没写对，而要看检查结果是否随配置变化而变化。最直接的做法是：先记录当前死链数量和具体URL，再修改一条配置，重新跑一次检查，对比结果是否按预期改变。如果结果不变，配置就没有生效。
准备阶段：先固定一个可对比的基线
在改动任何配置之前，先完整跑一次死链检查，把结果保存下来。需要记录的内容包括：检查时间、检查范围（哪些目录或URL前缀）、发现的死链总数，以及至少5条具体死链的完整URL和返回状态码。
- 如果工具支持导出，直接导出CSV或JSON作为基线文件。
- 如果不支持导出，手动复制结果列表，保存到本地文本文件。
- 记下本次使用的配置文件路径和检查命令，后续验证要用同一套。
这一步的关键是让“修改前”和“修改后”有可比对象。没有基线，就无法判断配置是否产生了实际影响。
实施阶段：用一条可预期的改动做验证
不要一次改多项配置，否则无法定位是哪一项在起作用。选择一条效果明确的规则来测试。例如，在忽略列表中新增一个确定存在的死链URL，或者在检查范围中排除一个包含死链的目录。
假设某个页面 /old-page.html 返回404，并且它出现在当前死链结果中。把这条URL加入忽略配置，保存后重新执行检查。这里的关键判断标准是：这条URL应当从结果中消失，而死链总数应当减少1。如果它仍然出现，说明忽略规则没有被读取，或者匹配方式写错了。
需要注意匹配方式。很多工具支持精确匹配、前缀匹配和正则匹配，写错类型会导致规则看似配置了却不生效。先用精确匹配测试，确认生效后再换成更复杂的匹配方式。
验证阶段：区分“配置未生效”和“配置生效但结果符合预期”
重新检查后，可能出现三种情况，需要分别判断：
- 目标URL消失，总数减少。配置已生效，且行为符合预期。
- 目标URL仍在，总数不变。配置未生效。可能原因包括：配置文件路径不对、工具未重新加载配置、规则语法错误、缓存了上次结果。
- 目标URL消失，但总数没变或变化异常。配置生效了，但可能同时触发了其他规则，或者该URL本来就被其他条件排除。需要单独核对该URL的状态码和匹配逻辑。
如果属于第二种情况，按顺序排查：确认命令读取的是你修改的那个文件；确认没有旧进程或缓存结果被复用；把规则简化到最小形式再测一次。不要同时怀疑多个原因，逐项排除。
维护阶段：把验证变成固定动作
配置生效不是一次性确认，而是每次改动后都要重新验证。建议在配置文件中保留注释，写明每条规则的目的和添加时间。每次修改后，至少做一次“改一条、跑一次、对一次”的循环。
另外，死链检查结果会随站点内容变化而变化。今天生效的忽略规则，可能因为页面恢复或URL结构改变而不再适用。定期用基线对比的方式复查，比只看配置文件是否存在更可靠。
下一步：打开你当前的死链检查配置，挑一条最容易判断效果的规则，按上面的方法跑一次对比，确认结果变化后再继续调整其他规则。
