500 错误本身不说明问题，关键是要看到它背后的异常堆栈——而 Laravel 默认就把这些信息记在 storage/logs/laravel.log 里。只要日志能写进去、内容没被吞掉，错误根源基本一目了然。
确保日志文件可写且路径正确
默认日志位置是 storage/logs/laravel.log，但前提是 storage/ 目录对 Web 服务器用户（如 www-data、nginx 或 apache）有写权限。常见于 Docker、Nginx 部署或 phpstudy 环境：
- 运行
ls -l storage/logs检查目录归属和权限，推荐设为775，用户组与 Web 进程一致 - 如果日志文件为空或报“failed to open stream”，八成是权限或 SELinux（Linux）/ 权限继承（Windows WSL）导致写入失败
- phpstudy 用户常因缺失
.env或.env.example导致环境未加载，连带日志配置失效
实时盯住日志，复现请求抓堆栈
别等刷新完再翻文件，用终端命令边操作边看：
-
tail -f storage/logs/laravel.log：持续输出最新日志，按 Ctrl+C 停止 - 在浏览器或 Postman 中触发一次出错的请求（比如访问某个 API 接口）
- 终端会立刻打出完整的异常类型、消息、文件路径和行号，例如：
Class 'App\Http\Controllers\XXXController' not found或Trying to get property 'name' of null
让错误不被隐藏：必须开启调试模式
如果日志里只有模糊的 “production error” 或干脆没记录，大概率是 APP_DEBUG=false 把异常细节过滤掉了：
- 编辑项目根目录下的
.env文件，确认两行配置： APP_DEBUG=true-
APP_ENV=local（或development） - 保存后清空缓存：
php artisan config:clear，再刷新页面，就能看到带堆栈的彩色错误页
日志里看到什么，就重点查什么
堆栈不是用来读完的，是用来定位第一行真实错误的：
- 出现
Class not found：检查命名空间、自动加载（composer dump-autoload）、文件是否存在 - 出现
Undefined variable或Call to a member function on null：回溯到控制器或视图中对应行，检查变量是否已赋值、模型绑定是否失败（如User $user传了不存在 ID 却又直接调用$user->name） - 出现
Too few arguments：通常是控制器方法参数类型提示与路由参数不匹配，或中间件提前终止了请求流程
