死链检测：文件路径大小写差异引发问题时怎样统一映射
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /aa4401890206.html
📄
死链检测：文件路径大小写差异引发问题时怎样统一映射
先给结论：大小写差异导致的死链，不能靠“把链接都改成小写”或“让服务器忽略大小写”二选一，而要先确定哪一侧是权威命名，再建立一张路径映射表，让检测工具、服务器配置和内容编辑都按同一张表执行。下面用一个假设情境说明这个决策过程。
假设情境：同一张图片，三个人看到三种结果
假设站点有一张图片，运营在后台填的路径是 /Images/Banner/Home.JPG，前端模板里写的是 /images/banner/home.jpg，而服务器实际存放的文件名是 Home.jpg。运营在本地预览时正常，前端在测试环境正常，上线后部分页面图片 404。三个人都认为“路径没错”，因为他们各自验证的环境不同。
这类分歧的核心不是谁粗心，而是同一事实在不同环节被规范化成了不同形式。要把它转成可核对的项目，第一步是固定证据：抓取每个页面的实际请求 URL、服务器返回状态码、以及服务器上真实存在的文件路径，三者并列比对。只有三者同时列出，才能看出差异发生在哪一层。
先判断差异发生在哪一层，再决定映射方向
大小写问题可能出现在三个位置，处理方式完全不同：
- 链接层：HTML 里写的路径与目标文件大小写不一致。此时改链接即可，但要确认是否有其他页面引用了同一路径。
- 文件系统层：服务器上同一目录存在
Home.jpg和home.jpg两个文件，或只有其中一个。Linux 文件系统区分大小写，Windows 通常不区分，迁移时最容易暴露。 - 服务器与 CDN 层：源站能匹配，但 CDN 缓存键按大小写区分，导致部分节点命中失败。
判断方法很直接：把请求 URL 和文件真实路径都改成小写后重新请求。如果 200，说明差异在链接层或文件命名层；如果仍 404，说明问题在服务器规则或缓存层。这个动作的结果决定下一步——链接层问题交给内容编辑批量修正，文件层问题需要开发介入重命名或补文件，缓存层问题则要清理对应缓存键。
建立统一映射表，而不是逐条改链接
当差异页面超过几十个时，逐条修改容易漏改，也容易在下次改版时复发。更稳的做法是维护一张路径映射表，至少包含四列：请求路径、真实路径、处理方式、负责人。例如：
- 请求
/Images/Banner/Home.JPG→ 真实/images/banner/home.jpg→ 处理方式：改链接 → 负责人：内容编辑 - 请求
/API/User/List→ 真实/api/user/list→ 处理方式：服务器加规则 → 负责人：后端
映射表的作用不只是记录，而是让死链检测工具的输出可以直接对照。检测工具报出的每一条 404，都能在表里找到对应行，避免“这条到底改没改”的反复确认。如果同一路径被多个角色引用，映射表就是唯一事实来源。
服务器规则与检测工具要指向同一套命名
有些团队选择在服务器层做大小写不敏感映射，让所有请求都能匹配到文件。这能快速止血，但有前提：需要确认服务器或 CDN 确实支持该规则，且不会影响其他依赖大小写区分的路径。如果站点同时存在 /User 和 /user 两个不同含义的路径，全局忽略大小写会把它们合并，反而制造新问题。
检测工具同样需要对齐。如果工具在抓取时自动把 URL 转成小写，它报出的“正常”可能掩盖真实 404。建议在检测配置里关闭自动规范化，保留原始大小写，再与映射表比对。这一步的影响是：检测结果从“看起来没问题”变成“能定位到具体差异行”，后续修复才有明确对象。
用一次回归验证确认映射生效
映射表执行后，不要只看首页或几个样本页面。把映射表中所有请求路径重新请求一遍，记录状态码变化，并确认没有新增 404。假设映射表有 120 条，修复后仍有 3 条 404，这 3 条可能属于服务器规则未覆盖或文件确实缺失，需要单独处理，而不是继续批量改链接。
验证时还要注意：状态码从 404 变成 200 只说明该请求当前可达，不代表其他引用同一路径的页面也已修正。因此回归范围应覆盖所有引用过该路径的模板和内容。完成这一步后，把映射表归档，作为下次改版或迁移时的检查依据，避免同类问题重复出现。
