死链检查方法：文件路径大小写差异引发问题时怎样统一映射
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6b5106833a8a.html
📄
死链检查方法：文件路径大小写差异引发问题时怎样统一映射
结论：如果服务器或构建流程对路径大小写敏感，而站内链接或站点地图沿用了不一致的大小写，那么死链检查方法的核心不是逐条改链接，而是先建立“大小写统一映射”再回写来源。这个结论只在一种前提下成立：同一资源的真实路径只有一个，其他大小写变体只是引用错误。若站点确实存在两个大小写不同、内容也不同的目录，统一映射就会把正常页面误判为重复，必须先拆分资源再处理。
先验证大小写敏感是否真的在起作用
路径大小写差异是否致命，取决于运行环境。Linux 文件系统通常区分大小写，部分容器镜像和静态托管默认也区分；Windows 文件系统通常不区分。因此，同一批链接在本地预览正常、部署后 404，并不一定说明链接写错了，也可能只是部署环境变了。
可核对的证据是：直接请求两个仅大小写不同的 URL，观察状态码和响应内容是否一致。若一个返回 200、另一个返回 404，说明该环境区分大小写，映射有必要；若两者都返回 200 且内容相同，说明当前有重写或大小写不敏感机制在兜底，但这不等于永久安全，构建或托管配置变化后可能失效。若两者都返回 200 但内容不同，则属于真实的多资源冲突，不能简单合并。
实际操作：先抽取站内链接、站点地图和重定向规则中所有路径，按小写归一后统计每个归一形式对应多少个原始写法。结果只有一种写法，说明无冲突；出现两种以上写法，才进入映射流程。这个统计结果决定下一步是批量改写还是逐条判断，而不是凭感觉全站替换。
建立映射表时要区分三类路径
统一映射不是把所有路径都转成小写就结束。需要先分类，因为三类路径的处理方式不同。
- 静态资源路径：图片、样式、脚本、字体。这类路径通常由构建工具生成，适合以构建产物为准，统一按小写输出，并在引用处同步。
- 内容页路径：文章、产品、分类页。这类路径可能被外部链接和用户收藏引用，改动要考虑旧地址是否仍能访问。
- 带参数或动态段的路径：查询参数、动态路由段。大小写差异可能被程序逻辑放大，需要看后端路由是否区分大小写，不能只看文件系统。
映射表的每一行至少包含：原始写法、归一写法、真实资源位置、处理方式、是否需要重定向。处理方式只有三种：直接改写引用、保留旧写法并加重定向、标记为冲突待人工确认。把“待人工确认”单独列出，能避免自动化脚本误伤真实存在的多资源。
一个假设例子：映射后反而出现更多异常
假设某站点把全部内部链接统一改为小写，部署后却发现部分页面开始返回 404。直觉会认为“统一小写”出错了，但更合理的解释可能是：这些页面的真实目录名本身包含大写，服务器区分大小写，而映射表把真实路径也改成了小写。
此时可核对的证据是：对比映射前后的请求日志，看 404 是否集中出现在原本真实路径含大写的资源上。若是，则问题不在“统一”，而在“把真实路径和引用路径混为一谈”。正确做法是：真实路径保持不变，只统一引用写法；若必须改真实路径，则旧路径要保留重定向。这个反例说明，映射的边界是“引用层”，不是“存储层”。
回写来源并验证映射是否闭环
映射表确认后，动作顺序会影响排查成本。建议先改站点地图和站内链接，再改重定向规则，最后改构建配置。原因是：站点地图和站内链接是爬虫最常接触的入口，先改它们能最快减少新产生的错误引用；重定向规则用于兜住旧地址；构建配置改动影响面最大，放在最后便于回滚。
实际操作：改完后重新抓取一批代表性 URL，按归一形式分组，检查每组是否只指向一个真实资源，且该资源返回预期状态码。若某组仍出现两种状态码，说明映射未闭环，需要回到映射表检查是否漏了动态段或参数大小写。这个验证结果直接决定是否可以进入下一步的全量替换，而不是直接全站发布。
需要提醒的是，站点地图不保证收录，重定向也不等于索引立即更新。若发现抓取量或请求量在改动后短暂下降，不要立刻断定映射做错了，它也可能是抓取节奏调整或缓存刷新造成的。区分这些解释，需要结合状态码分布和真实路径命中情况，而不是只看单一指标。
什么时候不该做统一映射
如果站点同时存在 /Docs/ 和 /docs/ 两个真实目录，且内容不同，那么统一映射会破坏其中一个。此时应先确认业务是否真的需要两个目录；若不需要，合并内容并保留重定向；若需要，则应在链接和站点地图中明确区分，并检查服务器是否支持分别访问。这个条件不满足时，本文的结论不适用。
