500错误没日志？先确认APP_DEBUG是否真开启了
很多情况下你以为开了APP_DEBUG=true，其实根本没生效——Laravel在生产环境会强制忽略.env里的设置，只认config/app.php中debug键的值。更常见的是缓存没清，改了.env但php artisan config:clear没跑，导致还是用的旧配置。
-
APP_ENV=local和APP_DEBUG=true必须同时满足，缺一不可 - 改完
.env后务必执行php artisan config:clear（不是cache:clear） - 如果用的是Nginx + PHP-FPM，检查
fastcgi_param有没有把APP_DEBUG透传进去（有些部署脚本会覆盖环境变量） - 运行
php artisan tinker，输入config('app.debug')，看返回是不是true——这是唯一可信的判断方式
开了Debug还是只显示“Whoops”，看不到真实错误？检查Whoops\Handler\PrettyPageHandler是否被禁用
Laravel 9+ 默认用filp/whoops，但如果你装过barryvdh/laravel-debugbar或自定义过异常处理逻辑，可能意外替换了render()方法，导致错误堆栈被吞掉。另外，某些PHP扩展（比如xdebug.mode=off）也会让Whoops降级为白屏。
- 检查
app/Exceptions/Handler.php里render()方法是否被重写且没调用parent::render() - 在终端运行
php --ini确认xdebug.ini是否加载，再查php -i | grep xdebug.mode，值必须包含develop或off以外的内容 - 临时删掉
bootstrap/cache/config.php，避免缓存干扰调试 - 直接访问
/foo/bar这种肯定404的路由，如果看到完整Whoops页面，说明500错误本身被框架外层捕获了（比如中间件抛异常）
错误日志里只有PHP Fatal error: Allowed memory size exhausted？别急着加内存
这个报错常出现在模型大量关联、Blade模板递归渲染、或队列任务里反复new同一个服务实例。单纯调大memory_limit只是掩盖问题，而且线上环境不允许无限制扩容。
- 用
php artisan tinker执行ini_get('memory_limit')确认当前限制 - 在
AppServiceProvider::boot()开头加echo memory_get_usage() . "\n";，快速定位内存飙升点 - 查
storage/logs/laravel.log里500前几行，重点找Undefined variable、Call to a member function on null这类错误——它们常因未判空导致后续无限循环 - 如果用
DB::listen()监听SQL，记得在回调里加if (app()->environment('local'))，否则日志量爆炸
本地能跑，上线就500？重点盯storage权限和opcache.revalidate_freq
Linux服务器上storage和bootstrap/cache目录权限不对，会导致Laravel写不了日志、缓存、session，直接500；而Opcache在revalidate_freq=0时不会检查PHP文件更新，改了代码却还在跑旧字节码，容易触发类找不到或方法不存在。
- 确保
www-data（或对应Web用户）对storage和bootstrap/cache有读写权限：chown -R www-data:www-data storage bootstrap/cache - 检查
php.ini中opcache.revalidate_freq，开发环境建议设为0，生产环境至少2 - 部署后执行
php artisan optimize:clear，它比单独清缓存更彻底 - 用
ls -la storage/logs确认日志文件属主是否是Web用户，否则APP_DEBUG=true也吐不出错误
