apache重写错误时yii2不显示真实错误，因请求未进入php层；需启用mod_rewrite、设置loglevel rewrite:trace3、检查allowoverride，并查error.log中rewrite:trace行定位问题。
Apache 重写规则出错时，Yii2 默认不显示真实错误，只返回空白页或 404/500，必须手动打开底层报错通道才能看到 .htaccess 或 Apache 配置的真实问题。
为什么浏览器只显示空白或 404，却看不到具体错误
因为 Apache 在 .htaccess 解析失败、规则语法错误、模块未启用等情况下，往往静默降级为“文件不存在”逻辑，不抛出可读提示；而 Yii2 的 ErrorHandler 根本没机会介入——请求压根没进 PHP 层。
-
RewriteRule写错（比如漏RewriteEngine On）会导致整段被忽略，Apache 返回 404，但日志里可能只记一条“file does not exist” - 规则触发无限重定向（如
RewriteRule ^(.*)$ index.php缺条件）会直接返回 500，Apache 错误日志里出现Request exceeded the limit of 10 internal redirects -
AllowOverride None时，.htaccess完全不生效，所有美化 URL 请求都 404，且无任何警告
怎么让 Apache 把重写错误打出来
不能靠 Yii2 日志，得查 Apache 自己的错误输出。关键三步：开模块、开日志、开重写调试。
- 确认
mod_rewrite已加载：apachectl -M | grep rewrite，没输出就运行a2enmod rewrite（Ubuntu/Debian）或取消httpd.conf中LoadModule rewrite_module modules/mod_rewrite.so的注释（CentOS/RHEL） - 在 Apache 主配置或虚拟主机中加两行：
RewriteLogLevel 3和RewriteLog logs/rewrite.log（Apache 2.2）；Apache 2.4+ 改用：RewriteEngine On+LogLevel alert rewrite:trace3，然后查logs/error.log - 重启 Apache 后用
curl -I http://localhost/test触发一次请求，再立刻看error.log，搜索rewrite:开头的行，就能看到每一步匹配、跳过、重写的完整链条
常见重写错误对应的日志关键词
不用猜，直接搜日志里的固定字符串：
-
Invalid command 'RewriteEngine'→mod_rewrite没启用或拼写错误（注意大小写） -
Request exceeded the limit of 10 internal redirects→ 规则循环，大概率缺RewriteCond %{REQUEST_FILENAME} !-f和!-d -
File does not exist: /path/to/web/css/style.css→ 静态资源被错误重写，说明豁免条件没生效或顺序错了 -
Options FollowSymLinks or SymLinksIfOwnerMatch is off→Options +FollowSymLinks没写或被覆盖
绕过 .htaccess 直接验证重写是否生效
如果日志没线索，最干脆的办法是跳过 .htaccess，把规则挪到 Apache 虚拟主机配置里，强制让它执行：
- 编辑
vhost配置，在<directory></directory>块内直接写：RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php [L] - 删掉 web 目录下的
.htaccess，重启 Apache；如果这时能访问美化 URL，说明问题纯属.htaccess权限或路径问题（比如AllowOverride没开对目录） - 若仍不行，说明规则本身有硬伤——比如
index.php路径不对（应是相对于 DocumentRoot 的路径），或RewriteBase缺失（子目录部署时必需）
真正卡住的点往往不是规则写法，而是 Apache 是否真的在读它、有没有权限读、模块是否真加载、以及日志级别是否够高——先盯死这四件事，比反复改正则更省时间。
