URLPattern前端路由匹配怎样减少手写正则怎样在批处理代码中减少额外分配

URLPattern 可以把路径规则写成 /items/:id，用命名参数代替手写捕获组。要减少批处理中的额外分配，应把模式实例移到循环外，按需要选择布尔匹配或参数提取，并直接累计业务结果；不能仅因为改用 URLPattern 就宣称更快或零分配。

官方标准地址：https://urlpattern.spec.whatwg.org/

背景：拆开规则表达与批处理成本

手写正则并非不能用，问题在于把路径拆分、查询串排除、捕获组位置以及业务优先级混在一起。本文限定为已知两条路径规则的客户端分类与参数提取，不实现完整 SPA 路由器。URLPattern 负责 URL 组件匹配，导航、页面加载和权限检查仍由应用负责。

把路由规则保存在初始化边界

下面代码在模块初始化时创建 routes，detailPattern 与 listPattern 分别引用其中两条模式。resolveOne 只返回 routeName 和所需 id；pathname.groups.id 是命名参数的读取位置。示例为独立原创写法，未在本文执行。

// 初始化时定义规则，避免在每个地址的匹配循环中重新构造模式。
if (typeof URLPattern !== "function") {
  throw new Error("当前环境缺少 URLPattern，请先加载兼容实现");
}
const routes = [
  { name: "detail", pattern: new URLPattern({ pathname: "/items/:id" }) },
  { name: "list", pattern: new URLPattern({ pathname: "/items" }) },
];
const detailPattern = routes[0].pattern;
const listPattern = routes[1].pattern;

function resolveOne(pathname) {
  // 输入约定为已解析的 pathname，不把查询串一起放进来。
  for (const route of routes) {
    const match = route.pattern.exec({ pathname });
    if (match !== null) {
      return {
        routeName: route.name,
        id: match.pathname.groups.id ?? null,
      };
    }
  }
  return null;
}
// 固定路由放在参数路由前面，可实现应用自己定义的优先级。

对象形式只指定 pathname，其余模式组件不承担同源限制。参数模式允许任意符合该段规则的值；如果业务只接受数字 ID，应在取值后另外判断。尾部斜杠也要作为业务规则显式决定，不能假设所有写法自动等价。

批量只分类时直接累计数量

当任务只是统计详情页和列表页数量，没有必要为每个地址保留完整匹配对象，更不必先 map 得到全部结果再 filter。countRoutes 直接遍历 paths，使用 pattern.test，结果存在 counts，invalid 只记录不满足本文输入契约的值；格式正确但没有命中路由的路径不增加计数。

function countRoutes(paths) {
  // 计数容器仅属于本次调用；规则表只读共享。
  const counts = Object.create(null);
  let invalid = 0;
  for (const pathname of paths) {
    if (typeof pathname !== "string" || !pathname.startsWith("/")) {
      invalid++;
      continue;
    }
    for (const route of routes) {
      // 只要布尔结果，不再先 test 后 exec，也不创建匹配结果数组。
      if (route.pattern.test({ pathname })) {
        counts[route.name] = (counts[route.name] ?? 0) + 1;
        break;
      }
    }
  }
  return { counts, invalid };
}
// 业务真的需要逐条参数时，再调用 resolveOne 并保留必要字段。

这减少了代码显式创建的中间数组和每项结果对象，仍然会创建一次 counts、一次返回对象以及调用中使用的输入对象。浏览器内部如何分配不受本文保证。若需要每个地址的参数，直接 exec 一次并处理 null，比先 test 再 exec 更符合任务需求。

把完整地址解析留在输入边界

以上函数接收路径，不接收完整 URL。外部输入例如 /items/28?tab=info 应先解析为 pathname；否则把问号后的内容当路径会改变匹配含义。以下适配器同时限定来源，捕获无法解析的输入，不把坏地址混入正常结果。

function pathnameOf(raw, baseURL) {
  // 在输入边界解析完整或相对地址；解析错误显式归入无效输入。
  try {
    const url = new URL(raw, baseURL);
    if (url.origin !== new URL(baseURL).origin) return null;
    return url.pathname;
  } catch {
    return null;
  }
}
// 示例域名仅用于解释，部署时传入应用自己的可信基准地址。
const path = pathnameOf("/items/28?tab=info", "https://example.com/");
const route = path === null ? null : resolveOne(path);

生产中的固定 baseURL 可在外层预解析为一个 URL 并缓存 origin，避免每条输入反复构造基准对象。如果输入本来就是可信 pathname，便不需要这层解析。不要为省对象而复用一个可变参数对象并把它传给会异步保存引用的业务回调。

兼容性与采用建议

MDN 将 URLPattern 标为 Baseline 2025 的新近可用特性，旧设备仍应做能力检测。缺失原生实现时，可加载经过项目评估的兼容实现，再初始化规则；既有成熟框架不必仅为替换正则而重写路由层。

性能结论需要同一批输入、同一匹配语义和相同结果消费方式下的测量，分别看耗时与内存。本文只给出可减少显式临时容器的代码组织方法，不提供加速比例，也不把示意图当实测证据。

相关问题

为什么相对地址字符串没有命中？

字符串形式的相对 URL 需要提供 baseURL；只匹配路径可以使用本文的对象输入形式。对象输入不能再把基准地址作为第二个位置参数传入。

URLPattern 能替代服务端权限判断吗？

不能。客户端规则只决定界面行为，数据权限仍由服务端独立执行。

可以缓存所有地址的结果吗？

只有输入重复且缓存有明确上限时才值得考虑。一次性批次保留整个匹配结果缓存反而会延长对象存活时间。

技术资料：https://developer.mozilla.org/en-US/docs/Web/API/URLPattern；https://developer.mozilla.org/en-US/docs/Web/API/URLPattern/test；https://developer.mozilla.org/en-US/docs/Web/API/URLPattern/exec。