PHP动态路由首选preg_match但需优化：预编译规则、锚定开头结尾、用1+替代.*、命名捕获组；高QPS重复前缀场景用Trie树（如nikic/fast-route）；务必标准化REQUEST_URI路径并二次校验参数。/ ↩
PHP 用 preg_match 做动态路由匹配最常用，但别直接写死正则
绝大多数 PHP 路由库（包括 Laravel、Slim 底层）第一反应就是 preg_match，因为它灵活、无需预编译结构、开发期调试直观。但问题在于：每次请求都重新解析整条规则，如果路由表有 50+ 条，且含大量捕获组或回溯敏感模式（比如 .* 后接可选字符），性能会明显下滑。
实操建议：
- 把路由规则提前编译成数组，避免每次
foreach都调用preg_match；优先用^/user/(?<id>\d+)$</id>这类锚定开头结尾的写法，减少回溯 - 避免在正则里用
.*匹配路径段，改用[^/]+——/post/(.*)可能误吞后续斜杠，而/post/(?<slug>[^/]+)</slug>更安全 - 捕获组命名统一用
(?<name>...)</name>，后续取值直接$matches['name']，比数字索引更可维护
什么时候该上 Trie 树？不是为了炫技，而是 URL 前缀高度重复
Trie 树适合场景很具体：你的路由大量是 /api/v1/users、/api/v1/posts、/api/v2/users 这种共享长前缀的 RESTful 接口，且 QPS 较高（比如 >500 req/s）。此时 preg_match 每次都要从头扫描整个正则，而 Trie 只需按字符逐级跳转，O(m) 时间（m 是 URL 长度），无回溯风险。
但代价是内存和初始化成本：你要把所有路由规则构建成树节点，还要处理通配符（如 :id 或 *）的特殊分支逻辑。别自己手撸——用现成的 nikic/fast-route，它内部就用分层 Trie + 正则 fallback 混合策略。
立即学习“PHP免费学习笔记（深入）”；
常见错误现象：fast-route 报 RouteNotFoundException 却没走 fallback，大概率是你注册路由时用了 get() 但实际发了 POST，或者没调用 $dispatcher->dispatch($httpMethod, $uri) 的返回值判断类型。
$_SERVER['REQUEST_URI'] 和 parse_url() 配合不好，路由就错一半
很多人直接对 $_SERVER['REQUEST_URI'] 做正则匹配，忽略了查询参数和编码问题。比如 /user/张三?tab=profile，若没先剥离 ?tab=profile，正则可能因 URL 编码（%E5%BC%A0%E4%B8%89）或问号本身失败。
正确做法是先标准化路径部分：
- 用
parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)提取纯路径，丢掉 query 和 fragment - 再用
rawurldecode()解码（注意不是urldecode()，后者会把+当空格处理） - 最后确保路径以
/开头且不以/结尾（除非你明确支持末尾斜杠），避免/user/123/和/user/123被判为不同路由
示例：rawurldecode(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)) —— 这行代码应该出现在路由分发器最开头。
带可选参数和嵌套路由时，正则顺序和贪婪性必须人工控制
比如想同时支持 /blog 和 /blog/2024，有人写 ^/blog(/(?<year>\d{4}))?$</year>，看似合理，但若后面还有 /blog/archive 规则，顺序一错就会被前面的“可选年份”吃掉。
关键点在于：路由匹配必须从最长、最具体的规则开始试，不能依赖正则“更贪婪就优先”。所以：
- 把带固定后缀的放前面，比如
/blog/archive→/blog/(?<year>\d{4})</year>→/blog - 避免用
.*或.+匹配中间段，改用非贪婪.*?并加边界，比如/post/(?<slug>[^/]+?)-(?<id>\d+)</id></slug> - 如果用
fast-route，它的{id:\d+}语法本质是生成带边界的正则，比手写更稳；但自定义正则时，一定要测试/user/123abc这类非法 ID 是否真被拦截
最容易被忽略的是：路由参数校验不该只靠正则，匹配成功后还得做二次类型检查（比如 $id = (int)$matches['id']; if (!$id) die();），否则字符串 0000 或负数可能绕过。
