最可靠方式是解析$_SERVER['REQUEST_URI']提取路径并去除查询参数，统一rtrim处理尾部斜杠，用^和$锚定正则路由，按 specificity 降序排列，通过反射转换参数类型，最后显式处理404。
PHP原生路由怎么匹配当前请求路径
直接读取 $_SERVER['REQUEST_URI'] 是最可靠的方式，它包含完整路径（含查询参数），但你要先去掉 query string 才能做路由匹配。别用 $_SERVER['PATH_INFO'] —— 它依赖 Web 服务器配置（如 Apache 的 AcceptPathInfo 或 Nginx 的 fastcgi_split_path_info），本地测试和线上行为不一致是常见翻车点。
实操建议：
- 用
parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)提取纯净路径，比如/user/123?tab=profile→/user/123 - 统一在开头对路径做
rtrim($path, '/')，避免/user/和/user被当成两个路由 - 如果项目部署在子目录（如
https://example.com/myapp/），需手动截掉前缀，不能硬编码/myapp，建议从$_SERVER['SCRIPT_NAME']推导基础路径
怎么写正则路由规则才不会漏匹配或过度匹配
正则路由比静态字符串灵活，但也更容易出错。核心原则是：锚定开头和结尾，用非贪婪捕获，显式声明分隔符边界。
常见错误现象： /user/123/edit 同时匹配了 /user/{id} 和 /user/{id}/edit，导致后者永远进不去。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 每条正则必须以
^开头、$结尾，例如^/user/(\d+)$，而不是/user/(\d+) - 路径段之间用
/显式分隔，避免^/user/(\d+)/?$这种模糊写法 ——/?会让/user/123和/user/123/都命中，但语义不同 - 捕获组优先用命名式（
(?P<id>\d+)</id>），调试时var_dump($matches)更直观；但注意 PCRE 版本兼容性，PHP 5.2+ 都支持 - 把更具体的路由（如
/user/{id}/delete）放在更宽泛的（如/user/{id}）前面，顺序就是优先级
怎么把路由参数安全地传给控制器方法
别直接 call_user_func_array([$controller, $method], $params) 就完事。PHP 不会自动类型转换，$id 从 URL 来永远是字符串，而你的 UserController::show(int $id) 在启用了严格类型检查时会报 Fatal error: Uncaught TypeError。
实操建议：
- 提前根据控制器方法的反射信息（
new ReflectionMethod($controller, $method)）读取参数类型，对int、bool等标量类型做强制转换 - 跳过类类型提示（如
Request $request），这类对象应由路由系统之外的容器注入，不是从 URL 解析来的 - 对未声明类型的参数，保留原始字符串值；对声明为
string的也别强行 trim 或 strtolower —— 保持原始输入，由业务逻辑决定是否处理 - 务必验证参数数量：反射拿到的必填参数个数，必须 ≤ 实际解析出的参数个数，否则说明路由定义和控制器签名对不上
为什么 404 总是不触发或触发得太晚
404 不是“没匹配到任何路由”就自动发生的。很多手写路由在循环完所有规则后忘了加兜底逻辑，或者把 http_response_code(404) 放在了输出 HTML 之后，导致 HTTP 状态码已发成 200，浏览器收不到 404。
实操建议：
- 所有路由匹配逻辑结束后，必须有一个明确的
if (false === $matched)分支，且在这个分支里第一件事就是http_response_code(404) - 禁止在路由分发前输出任何内容（包括空格、BOM、
echo ''），否则 header() 会失败，状态码无法修改 - 如果用了
require加载控制器文件，确保那些文件顶部没有echo、print或裸 HTML；最好用return而非echo输出响应体 - 开发期加一句
ini_set('display_errors', '1');，让 404 页面本身出错时也能看到 fatal error，而不是静默白屏
真正的难点不在写几条 if 或正则，而在于路径解析、参数绑定、错误响应这三者的时序和边界控制——少一个 rtrim，多一个空格，都可能让整个路由链失效。
