浏览器是否对URL片段进行模糊匹配？规则及浏览器差异咨询

核心结论 #

这不是浏览器的模糊匹配，而是主流浏览器都遵循W3C制定的URL片段匹配规范，同时适配了GitHub这类平台对锚点ID的特殊处理逻辑。

可依赖的锚点匹配规则 #

浏览器处理URL片段时，会按以下逻辑依次匹配页面元素：

• 优先精确匹配：首先查找与片段完全一致的id属性元素，比如完整的#user-content--why-are-rubys-floats-imprecise会直接定位到对应ID的元素。
• 自动移除平台前缀：当精确匹配失败时，多数主流浏览器会自动识别并移除常见平台的锚点前缀（比如GitHub统一添加的user-content-），再用剩余片段尝试匹配。这就是#-why-are-rubys-floats-imprecise能生效的原因——浏览器去掉隐含的user-content-前缀后，剩下的部分刚好和元素ID的后半段完全匹配。
• 大小写兼容匹配：规范允许浏览器对片段和ID进行大小写不敏感匹配，比如#FooBar可以匹配id="foobar"，不过这一点在旧版浏览器中可能存在严格匹配的情况。
• 转义字符自动解析：浏览器会自动处理URL片段中的转义字符，比如将%20转换为空格后再匹配元素ID。

主流浏览器的差异 #

目前Firefox、Edge、Brave（包括Chrome）在锚点匹配上的核心逻辑高度一致，但存在细微差别：

• 前缀识别范围：不同浏览器对「常见平台前缀」的覆盖范围略有不同，GitHub的user-content-是多数浏览器都能识别的，但其他小众平台的自定义前缀可能只有部分浏览器支持自动移除。
• 大小写匹配严格度：部分旧版浏览器可能强制要求大小写精确匹配，而新版主流浏览器普遍支持大小写不敏感匹配。
• 特殊字符处理：对于包含特殊符号的ID，不同浏览器的解析逻辑可能存在细微差异，但在常规使用场景下表现一致。

实用建议 #

虽然这种自动移除前缀的行为在主流浏览器中表现稳定，但不建议依赖这种非标准化的适配逻辑。最好始终使用页面元素的完整ID作为URL片段，避免因平台规则变更或浏览器版本更新导致锚点定位失效。

内容的提问来源于stack exchange，提问作者Burdette Lamar