重写规则错误导致404而非500，是因为Apache在请求进入PHP前执行RewriteRule，匹配失败或路径错误时按默认逻辑返回404；常见原因包括路径误写、正则开头斜杠冗余、缺失RewriteBase、规则顺序错乱等。
Apache 的 .htaccess 重写规则写错，直接导致整个站点或部分路由返回 404，不是 PHP 报错，也不是文件不存在——是请求根本没进到 PHP 层就被 Apache 拦下了。
为什么重写规则错会导致 404 而不是 500？
Apache 的 RewriteEngine On 开启后，每条 RewriteRule 都在请求进入 PHP 前执行。如果规则里用了不存在的路径、错误的标志（比如漏了 [L] 导致后续规则干扰）、或正则匹配失败又没 fallback，Apache 就会按默认逻辑处理请求——找不到对应文件/目录，就返回 404。
常见诱因包括：
-
RewriteRule目标路径写成/index.php?r=$1却没开启AllowOverride All或没启用mod_rewrite - 正则里用了
^/admin/（带开头斜杠），但在.htaccess中实际匹配的是相对路径，应写成^admin/ - 忘记加
RewriteBase /，导致重写后路径拼接错位 - 规则顺序颠倒，比如通用规则写在了精确规则前面，把本该放行的请求提前重写了
快速定位哪条规则出问题
打开 Apache 的重写日志（仅开发环境用），在 httpd.conf 或虚拟主机配置中加入：
立即学习“PHP免费学习笔记（深入）”；
RewriteLogLevel 3 RewriteLog "/var/log/apache2/rewrite.log"
注意：RewriteLog 和 RewriteLogLevel 在 Apache 2.4+ 已被移除，改用：
LogLevel alert rewrite:trace3
然后查日志里最后几行，看请求被哪条 RewriteRule 匹配、重写成了什么、是否最终落到真实文件上。
更轻量的办法：逐条注释 RewriteRule，从最后一条开始往上试，直到 404 消失——出问题的就在刚取消注释的那条附近。
PHP 应用常见重写陷阱（以 Laravel / ThinkPHP 为例）
很多框架文档给的规则抄来就用，但忽略部署路径差异。比如 Laravel 官方推荐：
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
这段在根目录没问题，但如果项目放在子目录如 https://example.com/myapp/，必须加 RewriteBase：
RewriteEngine On
RewriteBase /myapp/
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
否则所有请求会被重写成 https://example.com/index.php（而非 /myapp/index.php），Apache 找不到该文件，返回 404。
ThinkPHP 的 public/.htaccess 若被误放到项目根目录，也会因路径错位导致重写目标无效。
检查与验证流程（三步闭环）
别只改规则，要闭环验证：
- 运行
apachectl -t确认语法无误（避免配置写错直接让 Apache 启动失败） - 用
curl -I http://localhost/xxx看响应头中的Location或状态码，确认是否被重定向、是否卡在某层 - 临时在
index.php开头加var_dump($_SERVER['REQUEST_URI'], $_GET); die;，看 PHP 实际收到的原始 URI 是什么——如果这里还是原始路径（如/user/123），说明重写根本没生效；如果已是/index.php?r=user/123，说明重写成功，问题在 PHP 路由解析层
最常被忽略的一点：修改 .htaccess 后，浏览器可能缓存了 301 重定向，导致你以为规则还在生效。务必用隐身窗口或 curl -v 直接测，别信地址栏。
