问题现象与错误分析
在Apache服务器中，通过mod_rewrite模块移除URL中的.php扩展名是一种常见的实践，旨在提供更简洁的用户友好型URL。然而，当处理包含尾部斜杠的URL（例如example.com/test/）时，不当的重写规则可能导致500内部服务器错误。
考虑以下一组常见的重写规则：
Options +SymLinksIfOwnerMatch
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ $1.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
RewriteCond %{REQUEST_URI} ^(.*)//(.*)$
RewriteRule . %1/%2 [R=301,L]当用户访问example.com/test/时，预期是如果test.php存在，则内部重写到test.php；如果不存在，则可能返回404或由index.php处理。然而，上述规则会导致服务器返回500错误。
错误的核心在于，当请求example.com/test/时，RewriteRule ^(.*)$ $1.php会将$1捕获为test/，然后尝试重写为test/.php。服务器会反复尝试将test/重写为test/.php，但这个文件显然不存在。更关键的是，在重写循环中，RewriteCond %{REQUEST_FILENAME}\.php -f中的%{REQUEST_FILENAME}在每次循环中都会被评估，它指向的是原始请求的物理路径（例如/abs/path/to/test），而test.php可能确实存在于此路径下。这种条件判断与重写目标之间的不匹配，最终导致了无限重写循环，Apache服务器检测到此循环后会抛出500内部服务器错误。
立即学习“PHP免费学习笔记（深入）”；
核心问题：RewriteCond与RewriteRule的不匹配
上述问题的根本原因在于RewriteCond指令中的%{REQUEST_FILENAME}变量与RewriteRule指令中的$1变量所代表的含义在特定场景下的差异。
- %{REQUEST_FILENAME}: 这个变量代表了当前请求的完整文件系统路径。在重写规则处理之前，Apache会尝试将URL映射到服务器文件系统上的一个物理路径。因此，当请求example.com/test/时，%{REQUEST_FILENAME}会解析为/abs/path/to/test（假设test是一个目录或文件）。
- $1: 这是RewriteRule的正则表达式中捕获的第一个组。对于RewriteRule ^(.*)$ $1.php，当请求URL路径是/test/时，$1会捕获到test/。
问题在于，原始规则中的RewriteCond %{REQUEST_FILENAME}\.php -f在判断/abs/path/to/test.php是否存在，而RewriteRule ^(.*)$ $1.php却尝试将请求重写到test/.php。这两个目标是不一致的。当test.php文件确实存在时，条件%{REQUEST_FILENAME}\.php -f会为真，导致规则被执行。但执行结果是test/.php，这又是一个新的URL路径，再次进入重写引擎，重复上述过程，直到服务器崩溃。
解决方案：确保条件与重写目标一致
要解决这个问题，我们需要确保RewriteCond中检查的文件存在性与RewriteRule中实际重写的目标是完全一致的。正确的做法是使用%{DOCUMENT_ROOT}结合捕获组来构建RewriteCond的测试字符串。
RewriteCond %{DOCUMENT_ROOT}/$1.php -f
RewriteRule (.*) $1.php [L]让我们分析一下这个修改：
-
RewriteCond %{DOCUMENT_ROOT}/.php -f:
- %{DOCUMENT_ROOT}: 这个变量代表了Apache配置中网站的根目录。
- $1: 在RewriteRule (.*) $1.php [L]中，(.*)会捕获请求URL路径的全部内容。
- 通过将%{DOCUMENT_ROOT}/与$1.php拼接，我们构造了一个明确指向服务器文件系统上预期PHP文件的路径。
- 现在，当请求example.com/test/时，(.*)会捕获test/。RewriteCond会检查%{DOCUMENT_ROOT}/test/.php是否存在。由于通常情况下test/.php这个文件不会存在，所以此条件将为假，该RewriteRule不会被触发，从而避免了重写循环。
- 当请求example.com/test时，(.*)会捕获test。RewriteCond会检查%{DOCUMENT_ROOT}/test.php是否存在。如果存在，条件为真，规则被执行，内部重写到test.php。
-
*`RewriteRule (.) $1.php [L]`**:
- L标志（Last）：这是一个非常重要的标志，它告诉Apache在当前规则匹配并执行后，停止处理后续的重写规则。这有助于防止不必要的规则冲突和潜在的重写循环。原始规则中缺少此标志，可能导致即使匹配成功，处理也会继续到下一条规则。
Rewrite规则优化与最佳实践
除了上述核心修正，还有一些其他优化点可以使.htaccess配置更加健壮和高效：
[L] 标志的重要性: 如前所述，[L]标志是必不可少的。它确保一旦找到匹配的重写规则并执行，Apache将停止处理后续的RewriteRule，从而避免意外的链式重写。
移除冗余的 !-d 条件: 在RewriteCond %{REQUEST_FILENAME}\.php -f中，我们已经明确检查了某个文件是否存在。如果一个文件存在，它就不可能是一个目录，因此RewriteCond %{REQUEST_FILENAME} !-d这个条件是多余的，可以移除。
RewriteCond 中点号的转义: RewriteCond的第一个参数（TestString）在多数情况下不是正则表达式，因此像.这样的字符不需要反斜杠转义。例如，%{REQUEST_FILENAME}\.php可以写成%{REQUEST_FILENAME}.php，但这只是一个微小的语法点，不影响功能。
双斜杠重定向规则的放置: 用于处理URL中双斜杠（//）的重定向规则应该尽可能放在.htaccess文件的最前面。这是因为双斜杠通常是URL格式不规范的体现，应在任何其他重写发生之前进行标准化处理，以避免后续规则基于不规范的URL进行匹配。
完整优化后的Rewrite配置
综合以上分析和最佳实践，一个更健壮、更高效的.htaccess配置示例如下：
Options +SymLinksIfOwnerMatch
RewriteEngine on
# 1. 标准化URL：处理双斜杠，确保在所有其他重写之前执行
RewriteCond %{REQUEST_URI} ^(.*)//(.*)$
RewriteRule . %1/%2 [R=301,L]
# 2. 移除 .php 扩展名
# 确保 RewriteCond 检查的文件与 RewriteRule 重写的目标一致
RewriteCond %{DOCUMENT_ROOT}/$1.php -f
RewriteRule ^(.*)$ $1.php [L]
# 3. 如果请求不是文件也不是目录，则重写到 index.php（前端控制器模式）
# 此规则应在移除 .php 扩展名之后
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]总结
通过本文的详细分析，我们理解了在Apache RewriteRule中移除.php扩展名时，因RewriteCond与RewriteRule目标不一致而导致重写循环的根本原因。关键在于使用%{DOCUMENT_ROOT}/$1.php来确保RewriteCond的条件判断与RewriteRule的重写目标保持同步。同时，正确使用[L]标志、优化条件判断以及合理放置URL标准化规则，能够构建出更加稳定和高效的Apache重写配置。在编写和调试Rewrite规则时，务必牢记匹配条件与重写结果的一致性原则，这将大大减少潜在的错误和服务器问题。
