URL Rewrite 正确捕获 API 路径参数的完整解决方案-php教程-PHP中文网

URL Rewrite 正确捕获 API 路径参数的完整解决方案

本文揭示了一个常见却隐蔽的问题：看似 mod_rewrite 丢失 URL 最后路径段，实则源于 PHP 后端代码中意外的重定向逻辑干扰了 $_SERVER['REQUEST_URI'] 的原始值；修正后，重写规则本身完全可靠。

本文揭示了一个常见却隐蔽的问题：看似 `mod_rewrite` 丢失 url 最后路径段，实则源于 php 后端代码中意外的重定向逻辑干扰了 `$_server['request_uri']` 的原始值；修正后，重写规则本身完全可靠。

在使用 Apache mod_rewrite 构建 RESTful API 路由时，许多开发者会遇到“路径末尾参数消失”的假象——例如访问 /api/category/1 时，$_SERVER['REQUEST_URI'] 却显示为 /api/category/index.php，而加斜杠 /api/category/1/ 反而能正确捕获。这极易被误判为重写规则缺陷，但真实原因往往藏在 PHP 应用层。

你的 .htaccess 规则本身是完全正确的：

<ifmodule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^api/(.*)$ api/index.php?q=$1 [QSA,L]
</ifmodule>

✅ ^(.*)$ 已能贪婪匹配任意长度路径（含多级 /）；
✅ [QSA] 确保原始查询参数（如 ?u=1&k=4）自动追加；
✅ [L] 终止后续规则，避免冲突；
✅ 无需 RewriteBase（因项目位于子目录 myproject/，Apache 默认按请求上下文解析相对路径）。

问题根源在于：PHP 脚本中过早读取或修改了 $_SERVER 变量。正如答案所揭示，include_once('../constants.php') 和 db.class.php 中隐含的条件重定向（如基于 REQUEST_URI 的非法路径跳转），会在 index.php 主逻辑执行前篡改服务器环境变量——尤其是当重定向逻辑未严格区分「原始请求」与「重写后请求」时，$_SERVER['REQUEST_URI'] 可能被覆盖为重写后的内部路径（如 /myproject/api/category/index.php），造成“参数丢失”的错觉。

✅ 正确实践建议

延迟读取 REQUEST_URI：在所有 include/require 完成、且确认无重定向逻辑触发后，再获取原始 URI：

// api/index.php 开头
define('ORIGINAL_REQUEST_URI', $_SERVER['REQUEST_URI'] ?? '');
// 避免后续 include 中的代码污染此值

安全解析路由参数（推荐）：

$q = $_GET['q'] ?? '';
$pathParts = array_filter(explode('/', trim($q, '/')));
// $pathParts 将得到 ['categories'] 或 ['category', '1']

验证重写是否生效（调试必备）：在 api/index.php 顶部临时添加：
```
error_log("RAW REQUEST_URI: " . ($_SERVER['REQUEST_URI'] ?? 'N/A'));
error_log("REWRITTEN q PARAM: " . ($_GET['q'] ?? 'N/A'));
exit;
```
访问 http://localhost/myproject/api/category/1，检查日志中 q 是否为 category/1 —— 若是，则重写成功，问题必在后续 PHP 处理逻辑中。

⚠️ 注意：切勿在 index.php 中直接依赖 $_SERVER['PATH_INFO'] 或未经校验的 $_SERVER['REQUEST_URI']，因其易受 Apache 模块（如 mod_negotiation）、.htaccess 其他规则或第三方库影响。始终以 $_GET['q']（即重写传递的参数）作为路由主依据。

总结：mod_rewrite 是可靠的，真正的敌人是应用层对全局变量的不设防操作。通过分离重写逻辑（Apache 层）与路由解析（PHP 层）、延迟读取关键变量、并用日志验证各环节输出，即可彻底规避此类“幽灵问题”。