死链检查：文件路径大小写差异引发问题时怎样统一映射
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0455d0ff5f28.html
📄
死链检查：文件路径大小写差异引发问题时怎样统一映射
先给结论：只有当服务器文件系统区分大小写、而站内链接或重定向目标混用了大小写时，才需要做统一映射；如果服务器本身不区分大小写，这类死链通常不会出现，映射规则反而可能误伤正常路径。判断的关键不是链接写法好不好看，而是请求落到文件系统时是否真的找不到文件。
先确认大小写差异是否真的会导致 404
同一个 URL 在开发机上能打开、上线后变成死链，常见原因就是本地是大小写不敏感的文件系统，而生产环境是大小写敏感的。此时 /Images/Logo.png 和 /images/logo.png 指向两个不同结果，前者可能直接返回 404。
要区分两种情形。第一种是链接写错、文件实际存在，只是大小写不匹配；第二种是文件被改名或迁移，旧路径已不存在。前者适合做映射，后者只能重定向或删除入口。可以用一条命令验证目标路径的真实文件名，再与页面里出现的写法逐一对照，确认差异是纯大小写还是路径本身已经变化。
统一映射的可行做法与适用条件
统一映射的核心是建立一个“请求路径到真实文件路径”的对照关系，而不是简单地把所有 URL 强制小写。以下动作按优先级排列：
- 先导出真实文件名清单。在服务器上列出站内静态资源的实际路径，作为映射的唯一依据。
- 再导出站内引用的路径清单。从页面、样式表、脚本和重定向配置中提取所有被引用的路径。
- 做大小写不敏感的比对。把两边都转成同一大小写形式后匹配，找出“只差大小写”的条目。
- 对匹配项统一改成真实文件名的写法。改的是引用方，不是文件本身；文件重命名会制造新的死链。
- 对无法匹配的条目单独处理。这些属于路径已失效，应走重定向或下线，不要塞进大小写映射。
这套做法成立的前提是：差异确实只存在于大小写层面，且真实文件名稳定。做映射后，引用的路径与磁盘路径完全一致，后续死链检查中这类 404 会消失，下一步就可以把精力放在真正失效的链接上，而不是反复排查同一批大小写问题。
一个会让结论失效的反例
如果服务器或 CDN 对路径做了规范化，例如把请求统一转成小写再查找文件，那么“统一映射”可能完全没必要，甚至有害。假设真实文件名是 Logo.png，而中间层会把请求路径转成小写，那么即使你把站内引用改成 Logo.png，到达文件系统时仍可能变成 logo.png，依然找不到文件。
这种情况下正确的动作是改文件名或调整规范化规则，而不是继续改站内引用。判断方法是：直接请求一个已知大小写正确的路径，看返回的是文件内容还是重定向到另一个大小写形式。如果发生重定向，说明中间层在改写路径，映射策略要随之调整。
映射之后怎样验证并进入下一步
改完后不要只看首页。应针对之前出现 404 的具体路径逐个请求，确认返回状态码为 200，而不是 301 或 403。状态码从 404 变成 200 只能说明该路径已可访问，不能单独证明整站没有其他大小写问题，因为未被引用的路径可能仍存在差异。
验证通过后，下一步动作是把“大小写一致性”纳入构建或发布流程：在生成页面和资源引用时，统一使用真实文件名，而不是依赖人工检查。这样后续新增内容不会重新引入同类死链。若验证仍有失败项，说明差异不止大小写一种，应回到路径是否真实存在这一层重新分类。
