URLPattern前端路由匹配怎样减少手写正则怎样完成一个可复用的最小示例

我在整理一个前端入口时，最先遇到的不是路由数量太多，而是同一条路径被不同的正则写了几遍：列表页判断一次，详情页取参数又判断一次，查询字符串和路径边界还容易漏掉。这个场景可以交给 URLPattern：它按 URL 的组成部分匹配规则，能用 :id 这样的命名组直接取出参数。

官方文档：https://developer.mozilla.org/en-US/docs/Web/API/URLPattern

如果目标是“按路径分发页面，并取出少量命名参数”，先把规则写成 URLPattern，再用 test() 做布尔判断、用 exec() 取结果。规则集中后，手写正则只保留给真正需要复杂文本解析的地方。

先把路由规则放到 pathname 上

URLPattern 可以接收完整 URL 字符串，也可以接收按 URL 部件拆开的对象。前端路由通常只关心路径，因此对象写法更容易看出边界，也不必在字符串里处理协议、主机名和问号的转义。

// 将路由规则集中到 pathname，避免每个页面各写一套正则。
const routePatterns = {
  home: new URLPattern({ pathname: "/" }),
  articleList: new URLPattern({ pathname: "/articles" }),
  articleDetail: new URLPattern({ pathname: "/articles/:id" }),
};

// 这里的 :id 是命名捕获组，匹配后可以从 groups.id 读取。
console.log(routePatterns.articleDetail.test("https://example.com/articles/42")); // true
console.log(routePatterns.articleDetail.test("https://example.com/article/42")); // false

这段规则只约束 pathname。没有显式写出的 URL 部件会按 URLPattern 的默认规则处理；如果应用还要限制域名，可以同时写 hostname。对象语法也能避免把路径中的 ?、: 同 URL 部件分隔符混在一起。

用 test 判断，用 exec 取参数

test() 只返回布尔值，适合快速判断一条规则是否命中；需要把参数交给页面组件时，改用 exec()。匹配失败时，exec() 返回 null，所以不要直接访问结果属性。

// 把 URL 匹配与参数提取封装成一个小函数，失败时返回 null。
function matchArticle(url) {
  const pattern = new URLPattern({ pathname: "/articles/:id" });
  const result = pattern.exec(url);

  // exec 没有命中时返回 null，先判断再读取 groups。
  if (!result) {
    return null;
  }

  return {
    name: "article-detail",
    id: result.pathname.groups.id,
  };
}

console.log(matchArticle("https://example.com/articles/42"));
// { name: "article-detail", id: "42" }
console.log(matchArticle("https://example.com/articles"));
// null

命名组的价值在于调用方不需要记住第几个括号对应哪个字段。exec() 的返回对象还包含各 URL 部件的输入值；本文的最小路由器只取 pathname.groups.id，把其他细节留给确实需要它的场景。

把多条规则封装成可复用的最小匹配器

真正替代分散正则的关键，不是把每条规则包一层，而是规定匹配顺序和返回形状。静态路由放在动态路由前面，避免过宽的通配规则抢先命中；每条规则只返回自己的参数。

// 路由表按从具体到通用排列，避免动态规则提前吞掉静态路径。
const routes = [
  { name: "home", pattern: new URLPattern({ pathname: "/" }) },
  { name: "article-list", pattern: new URLPattern({ pathname: "/articles" }) },
  { name: "article-detail", pattern: new URLPattern({ pathname: "/articles/:id" }) },
];

// 只返回匹配到的路由和命名参数，页面入口不需要理解 URLPattern 细节。
function resolveRoute(url) {
  for (const route of routes) {
    const match = route.pattern.exec(url);
    if (match) {
      return {
        name: route.name,
        params: match.pathname.groups,
      };
    }
  }

  // 没有规则命中时交给 404 或兜底页面处理。
  return { name: "not-found", params: {} };
}

console.log(resolveRoute("https://example.com/articles/42"));
// { name: "article-detail", params: { id: "42" } }

如果将来增加 /articles/new，应把它放在 /articles/:id 前面，并在表中给出明确的名字。这样路由冲突能通过表的顺序显式解决，而不是靠几段难以维护的负向正则猜测。

相对 URL、大小写和兼容边界要单独处理

如果传入的是相对 URL，例如 /articles/42，就必须同时提供可解析的 baseURL；缺少基址时，test() 或 exec() 无法把它解析成完整 URL。生产代码可以在入口统一先拿到 location.href，这样匹配器只接收绝对地址。

URLPattern 默认区分大小写。如果路由确实不区分大小写，可以在构造时传入 { ignoreCase: true }，但更推荐先统一 URL 规范，再决定是否放宽匹配。构造器遇到无效模式、相对模式缺少基址等情况会抛出 TypeError，所以规则应在模块初始化阶段创建，而不是每次点击都临时创建。

MDN 当前将 URLPattern 标为 Baseline 2025，并提示旧设备或旧浏览器可能不支持。需要覆盖旧环境时，保留一个小型适配层：优先使用 URLPattern，检测不到时退回项目已有的简单路径解析函数；不要为了兼容而把所有规则重新散落到业务组件里。

最后用一张清单确认规则没有变复杂

• 只按路径匹配时使用 { pathname: "..." }，需要域名时再补 hostname。
• 只判断是否命中使用 test()，需要参数使用 exec() 并先判断是否为 null。
• 静态路径优先于动态路径，通配规则放在最后。
• 相对 URL 配置可解析的 baseURL，或在入口统一传入绝对 URL。
• 将浏览器支持检测放在适配层，避免把兼容分支扩散到每个页面。

URLPattern 适合做结构化 URL 的匹配和参数提取，不是所有正则需求的替代品。当前端路由的规则边界清楚时，它能让“路径是什么、参数叫什么、命中后返回什么”集中在一张小表里，维护成本通常比重复手写正则更低。

相关问题

URLPattern 能代替所有正则吗？

不能。它擅长 URL 各部件和命名组的匹配；如果要解析非 URL 文本，仍应使用正则或专门的解析器。

为什么 exec 返回 null？

常见原因是路径不符合模式、相对 URL 没有基址，或者输入 URL 本身无法解析。先确认传入的是完整 URL，再检查 pathname 是否带有预期的斜杠。