死链优化：文件路径大小写差异引发问题时怎样统一映射
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2a94b62a278b.html
📄
死链优化：文件路径大小写差异引发问题时怎样统一映射
结论先行：如果服务器或对象存储对路径大小写敏感，而站内链接、站点地图或历史外链混用了大小写，统一映射应当以“当前实际可访问的那个路径”为规范形式，再用服务器层重写把其余变体永久指向它；但如果你的运行环境本身大小写不敏感，这套映射只会掩盖问题，真正的修复应放在链接生成端。判断走哪条路，取决于一个可验证的前提：把同一路径的大写与小写变体分别请求一次，看返回状态码是否不同。
先确认大小写敏感是否真实存在
很多团队把“页面打不开”直接归因于大小写，但真正的原因可能是目录被改名、部署时文件名被转换，或者反向代理做了归一化。区分方法很直接：选取一个已知存在的文件，构造两个仅大小写不同的请求，例如 /Assets/Logo.png 与 /assets/logo.png，分别观察状态码、响应体和最终 URL。如果两者都返回 200 且内容一致，说明当前环境不敏感，大小写不是死链的根因；如果只有一种返回 200，另一种是 404 或 403，才进入映射方案。
这一步的结果决定后续动作：不敏感的环境下，继续加映射规则会制造重复 URL，反而让规范链接更难判断；敏感环境下，映射才是必要的兜底。
映射应该放在哪一层，取决于谁在产生错误链接
统一映射不是只有一种做法，常见有三个落点，适用条件不同：
- 服务器重写规则：适合历史链接和外部链接已经大量混用大小写、短期内无法逐一修改的情况。把已知的错误变体 301 到规范路径，能立刻止损。代价是规则会随路径增长而膨胀，且必须保证不产生重定向链。
- 应用路由归一化：适合路径由程序动态生成、且你能控制路由匹配逻辑的场景。在进入业务逻辑前把路径统一转为小写再做匹配，比逐条写重写规则更可持续。
- 链接生成端修正：适合错误只来自站内模板、导航或站点地图的情况。此时映射只是临时补丁，真正要做的是让输出链接的地方使用同一套规范形式，否则新页面会继续产生新变体。
选择依据不是哪个更“正确”，而是错误链接的来源是否还在持续产生。如果来源未切断，任何映射都会不断被新的变体绕过。
一个反例：映射会让问题看起来消失，但前提已经变了
假设某站点把图片目录从 /Images/ 改为 /images/，同时保留了旧目录的 301。此时大小写映射看起来工作正常，但真正的规范路径已经变成小写，而站点地图和模板仍在输出大写。这种情况下，映射让抓取端始终拿到 200，掩盖了生成端的不一致。一旦将来更换服务器或迁移到对大小写敏感的对象存储，旧规则未同步，死链会集中爆发。
所以映射成立的条件是：错误变体的来源已经停止或即将停止，映射只用于消化存量。如果来源仍在输出，映射就不是修复，而是延迟暴露。
落地时先做一次可复查的映射清单
在写规则之前，先用日志或抓取记录整理出“请求路径 → 实际存在的规范路径”对照，只保留确实返回 404 或 403 的变体。对每一条，确认规范路径当前可访问，再决定用 301 还是 308。动作上，先在一个小范围（例如单个目录）加规则并复查状态码链，确认没有多跳重定向后，再扩展到全站。这个顺序的影响在于：如果先全站铺开，一旦某条规则指向了同样不存在的路径，你会得到一批新的 404，排查成本远高于分批验证。
另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，所以不要用“已加站点地图”当作映射生效的证据，仍要回到状态码和最终 URL 上核对。
下一步动作
先完成敏感性与来源两项确认：环境敏感且来源仍在输出时，优先修链接生成端，映射只作过渡；环境敏感且来源已停止时，按目录分批加映射并复查重定向链；环境不敏感时，把精力转向真实的改名或部署问题，不要引入大小写映射。做完这一步，再决定是否需要把规范路径写入站点地图和模板，避免下一轮迁移时重复同样的排查。
