404notfound：路径大小写差异引发时怎样统一映射
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /22b5e39a07b6.html
📄
404notfound：路径大小写差异引发时怎样统一映射
结论先说：只有当你确认大小写差异来自可控的链接生成或重定向链路，并且服务端能稳定拿到原始请求路径时，才适合用统一映射把大小写变体收敛到同一目标；如果差异来自用户输入、外部引用或不同系统对同一路径的编码习惯，统一映射会把原本可区分的资源压成一个，先别做全站规则。
先判断：大小写差异是“同一资源”还是“不同资源”
统一映射的前提是这些路径在语义上指向同一份内容。判断依据不是看它们都返回404notfound，而是看三件事：源文件是否只有一个真实路径、链接生成端是否只应输出一种写法、以及重定向链路里是否出现了大小写改写。
- 同一资源信号：服务器文件系统本身不区分大小写，或内容库只存一条记录，但入口链接出现了多种大小写组合。
- 不同资源信号：路径在业务上代表不同对象，例如带编号、带语言码或带用户标识，大小写本身就是区分条件。
- 边界条件：如果站点同时存在静态文件和动态路由，静态部分可统一，动态部分必须先确认参数是否参与资源定位，不能直接照搬静态规则。
一个实际动作是：先抽取出现404notfound的请求路径，按“去掉大小写后是否完全一致”分组。如果一组里只有一个真实存在的目标，才进入映射候选；如果一组里对应多个目标，说明大小写不是噪声，而是资源标识的一部分，下一步应改为修正链接生成端，而不是加映射。
统一映射可以怎么做，以及它的失效点
在确认同一资源后，常见做法是在服务端把请求路径统一转成小写，再查一次路由或文件；命中后返回301到规范写法。这样做的直接结果是：后续抓取和用户点击都会落到同一个规范地址，重复入口减少。但它有一个明确的反例。
反例：假设某内容系统用路径末段的大小写区分草稿和已发布版本，例如 /Doc/abc 与 /doc/abc 分别对应两个状态。此时统一转小写会把两个状态压成一个，轻则展示错误版本，重则让本应保留的入口全部指向同一页。这个反例说明：统一映射只适用于“大小写不承载语义”的路径；一旦承载语义，映射规则必须排除这些前缀或段落。
因此，映射规则要写成有排除项的条件规则，而不是全站一刀切。动作上，可以先只对确认过的路径前缀启用，观察一段时间内这些前缀的404notfound是否减少、规范地址的抓取是否集中；如果规范地址的抓取没有集中，反而出现新的404notfound，说明映射目标或排除项写错了，下一步应回退规则并重新分组，而不是继续扩大范围。
规模化后出现例外时，先改链接生成端
个别样本成立、规模化后出现例外，通常不是因为映射规则本身错了，而是因为链接生成端仍在输出多种大小写。此时继续加映射，只会让规则越来越长，例外越来越多。
- 把映射规则命中的路径与链接生成端实际输出的路径做对照，找出仍在小写规范之外的那一类链接。
- 如果这类链接来自站内模板、站点地图或接口返回，优先修正生成端，让它只输出规范写法。
- 如果这类链接来自外部引用或用户输入，保留映射作为兜底，但不要指望它替代生成端修正。
这个顺序的影响是：先修生成端，映射规则才能保持短小稳定；反过来先堆映射，生成端的问题会被掩盖，后续每次新增内容都可能带出新的例外。
验证与下一步：用可区分证据决定是否继续
验证时不要只看404notfound数量是否下降。请求量归零还可能是因为抓取减少、入口下线或统计口径变化，不能单独证明映射正确。更可靠的证据是：同一组路径是否都落到同一个规范地址、规范地址是否成为主要被抓取入口、以及排除项对应的路径是否仍保持原样。
下一步动作可以按这个顺序：先确认大小写是否承载语义，再对确认的同一资源启用带排除项的映射，然后修正链接生成端，最后用规范地址的集中度和排除项路径的保留情况复查。只要排除项路径开始被错误合并，就说明当前映射范围过大，应回退到更小的前缀再试。
