线上display_errors关闭后500错误空白且无堆栈，主因是log::init()覆盖默认日志处理器或log.php中level为空/配置失效；需检查log::init调用、确保file驱动生效、设level为['error','critical']、启用apart_level、验证runtime/log可写并手动触发save()确认处理器注册。
线上环境display_errors关闭后，500错误只返回空白页，而日志里找不到堆栈、没有文件行号、甚至没Exception类名，根本无法判断问题出在哪一行代码——这不是配置漏了，是日志系统被悄悄覆盖或没激活关键捕获逻辑。
确认日志通道是否被Log::init()意外覆盖
检查common.php、app.php或服务启动流程中是否调用了Log::init()并传入了空数组或仅type配置。ThinkPHP默认用FileHandler捕获异常堆栈，但一旦Log::init()执行，它会【完全替换原生处理器】，导致后续所有Exception、Error都不进save()方法。
打开config/log.php，确认'default' => 'file'生效，且channels.file.type = 'File'未被其他配置覆盖。
若必须自定义日志，不要直接Log::init(['type'=>'File'])，改用Log::driver('file')->write()临时写入，避免破坏全局异常链。
强制日志级别包含error和critical
在config/log.php中，将level设为非空数组：
'level' => ['error', 'critical', 'alert']
空数组[]表示不记录任何级别；只写['error']可能漏掉critical级致命错误（如数据库连接彻底中断、内存耗尽）；【缺省level会导致Log::error()调用静默丢弃】。
修改后务必清空runtime/cache/，否则旧配置缓存仍生效。
启用独立错误日志并验证堆栈是否落地
第一步：在config/log.php的channels.file下添加：
'apart_level' => ['error']
第二步：确保runtime/log/目录存在且web服务器用户可写（如www-data有写权限）。
第三步：触发一次明确的报错，例如在控制器中写throw new \Exception('test log stack');
第四步：立刻查看runtime/log/error/目录下最新生成的error-YYYY-MM-DD.log，确认内容包含完整Trace、文件路径、行号及Exception类名——若只有[error]字样，说明上一步的level或apart_level未生效，或Log::init()仍在干扰。
手动触发Log::save()验证自定义Handler是否被调用
方法一：在App::after()钩子中插入
Log::save();
方法二：在自定义日志处理器的save()方法开头加调试语句：
file_put_contents('/tmp/log_called', date('Y-m-d H:i:s') . " save triggered\n", FILE_APPEND);
然后访问接口，再执行ls -l /tmp/log_called && tail /tmp/log_called。如果文件不存在或为空，说明你的Handler根本没被注册为默认驱动——检查Log::setDriver()是否执行，以及config/log.php中default值是否与driver名一致。
快速定位Nginx层与PHP层错误归属
当页面空白但runtime/log/无记录时，立即执行：
sudo tail -f /var/log/nginx/error.log | grep -E "(500|upstream|timeout|denied)"
若该命令实时输出“connect() failed”或“Connection refused”，说明问题在网关层：PHP-FPM未启动、端口不通、或Nginx配置了错误的fastcgi_pass地址。
若Nginx日志干净，再查PHP错误日志：
echo ini_get('error_log'); → 得到路径后tail -f该文件，复现操作看是否有Parse Error或Fatal Error记录。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
