嘿，这个问题我刚接触URL Pattern API的时候也踩过坑！咱们一步步把它掰扯清楚：

先给你吃个定心丸：这不是bug，是API特意设计的匹配规则 #

你测试的这段代码返回true完全符合API的设计逻辑，既不是隐藏特性，也不是你漏看了文档细节：

console.log( new URLPattern({pathname: '*/books'}).test({pathname: '/api/v1/books'}) )

核心原因：URL Pattern API的通配符与路径模式解析逻辑 #

咱们结合你提到的规范细节来拆解：

• 你说WHATWG规范要求路径名必须以/开头，这没错，但这是针对实际的URL路径名（比如你传入的/api/v1/books），而不是针对API的匹配模式。
• URL Pattern API的模式语法做了灵活扩展：当你写的路径名模式不以/开头但包含通配符*时，*会被解析为匹配任意数量的连续路径段（包括路径分隔符/）。
  拿你的例子来说，模式*/books里的*直接匹配了目标路径中的/api/v1部分，后面的/books正好对应目标路径的末尾段，所以整体匹配成功，返回true。

不同写法的匹配范围对比（帮你理清边界） #

为了让你更清楚，我列几个常见模式的区别：

• 模式/books：严格匹配仅以/books开头且没有后续段的路径，只会匹配/books，不会匹配/api/v1/books
• 模式/*/books：匹配包含**单前缀段+/books**的路径，比如/a/books、/v2/books，但不匹配/api/v1/books
• 模式*/books：就是你用的写法，匹配**任意数量前缀段+/books**的路径，比如/api/v1/books、/a/b/c/books都能命中

回到你提到的规范细节 #

你说的WHATWG里「canonicalize a pathname」要求路径名以/开头、路径名选项的delimiter和prefix设为/，这些都是API内部处理路径拆分的规则——它负责把路径拆成/分隔的段，而模式的语法允许用*跨段匹配，两者是互补的逻辑，并不冲突。

简单总结下：你遇到的是API为了提升匹配灵活性设计的常规特性，不是隐藏功能。如果需要更严格的开头匹配，只要给模式加上开头的/并调整通配符位置就可以啦！