死链接测试环境与线上怎样对照，先统一判定口径再比对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b783e45f3e2b.html
📄
死链接测试环境与线上怎样对照，先统一判定口径再比对
死链接在测试环境与线上要对照的，不是两份报告里“404数量”是否相等，而是同一批URL在两种环境下的状态码、跳转终点和可抓取性是否指向同一结论。正确做法是：用同一份URL清单、同一套请求规则分别抓取测试环境和线上，再按URL逐条比对差异，把差异归因到数据、配置或权限，而不是直接改测试环境去迎合线上。
先确定哪些差异属于正常范围
测试环境和线上本来就可能存在合理差异，例如测试库没有同步全部文章、图片域名不同、测试站默认禁止抓取。判断前先固定三个前提：
- URL清单来源一致，都来自同一份站点地图或同一轮站内抓取结果，而不是各抓各的。
- 请求方式一致，包括是否跟随跳转、是否带登录Cookie、User-Agent是否相同。
- 判定标准一致，例如把最终状态码为404、410视为死链接，把301、302视为跳转，把403、429单独归类为访问受限而非死链。
只有前提统一，差异才有比较意义。否则测试环境多出的404，可能只是数据没同步，而不是真的死链接。
具体对照步骤：同清单、双抓取、逐条比对
可以按以下顺序执行，每一步都有可检查的结果：
- 导出URL清单。从站点地图、导航、正文内链中收集同一批URL，存成一行一个地址的文本文件。
- 分别抓取。用同一脚本或同一工具，对测试环境和线上各请求一次，记录原始状态码、跳转链和最终URL。
- 生成对照表。字段至少包含：URL、测试状态码、线上状态码、测试最终URL、线上最终URL。
- 筛选差异。只保留状态码不同、或最终URL不同的行，其余视为一致。
- 逐条归因。对每条差异判断属于数据缺失、环境配置、权限限制还是真实死链。
例如假设某篇文章在测试环境返回404、线上返回200，检查后发现测试库没有导入该文章，这属于数据差异，不应改动线上链接。反过来，如果线上返回404、测试返回200，且测试数据与线上一致，那更可能是线上重写规则或文件缺失，需要优先处理线上。
用状态码和跳转终点做判断依据
对照时不要只看“是不是404”，而要看状态码和跳转终点是否一致：
- 两边都是200，且最终URL相同：一致，无需处理。
- 一边200、一边404：优先排查数据同步和服务器配置，确认哪边才是预期结果。
- 两边都301，但终点不同：说明跳转规则不一致，需要核对重写配置。
- 一边403、一边200：可能是测试环境开启了访问限制，属于权限差异，不能算死链接。
- 一边超时、一边正常：先排除网络和抓取频率问题，再判断是否为真实故障。
验收信号是：差异清单中每一条都能写明原因和处理动作；处理完成后重新抓取，同一URL在两边指向同一最终结果。若某条差异无法归因，应保留在清单中继续核查，而不是直接忽略。
历史入口和当前核查要分开
如果对照涉及旧版页面或已下线的功能入口，不要把过去的路径当成今天仍然可用的地址。正确做法是：在测试环境验证旧路径是否还配置了跳转，在线上确认该路径当前返回什么状态；两边都按当前实际响应判断，而不是依据记忆中的旧界面。
另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。对照时如果发现某URL在测试环境被robots.txt屏蔽、线上未屏蔽，这属于抓取策略差异，需要单独记录，不能和死链接混为一谈。
下一步：先跑一轮差异清单
选一份包含导航、正文内链和站点地图的URL清单，按上面的步骤分别抓取测试环境和线上，生成对照表并标注每条差异的原因。处理完数据同步和配置问题后，再重复一次抓取，确认两边对同一URL给出相同结论。
