本文揭示了一个常见却隐蔽的问题：看似 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 层）、延迟读取关键变量、并用日志验证各环节输出，即可彻底规避此类“幽灵问题”。
