500错误应先查日志，确认storage/logs/laravel.log可写且APP_DEBUG=true，实时监控日志复现请求；再排查API路由中间件、模型绑定、依赖注入及响应内容合法性。
500错误先看日志，别瞎猜
Laravel 返回 500 Internal Server Error，绝大多数情况不是服务器挂了，而是 PHP 抛出了未捕获异常，被框架兜底返回了 500。关键动作只有一个：查日志。
默认日志路径是 storage/logs/laravel.log，最新错误一定在文件末尾。用 tail -f storage/logs/laravel.log 实时盯住它，再复现一次请求，错误堆栈就出来了。
- 开发环境务必确保
APP_DEBUG=true（.env 中），否则错误细节全被吞掉，只留一个空 500 - 如果日志为空，检查
storage/logs/目录权限是否为 webserver 可写（常见于 Docker 或 Nginx 部署后） - 日志里若出现
Class not found或Undefined variable，直接对应到具体行号修复，别绕路
API路由报500？检查中间件和资源绑定
API 路由（routes/api.php）常因中间件或隐式模型绑定出错而静默 500。比如加了 auth:sanctum 但没传 token，或用了 Route::model('user', User::class) 却传了个不存在的 ID —— 这些不抛 HTTP 异常，而是触发 PHP 致命错误。
- 临时注释掉
api路由组里的中间件，确认是否由鉴权逻辑引发（如 Sanctum 的Guard::user()在无 token 时可能触发 null call） - 检查控制器方法参数类型提示，如
public function show(User $user)：若 URL 是/api/users/999且 DB 无该记录，Laravel 默认返回 404；但若模型绑定失败后你又手动调了$user->name，就会崩成 500 - API 路由默认不走
web中间件组（如 session、csrf），别误把需要 session 的逻辑塞进 api.php
500伴随“Too few arguments”或“Call to a member function”？盯紧依赖注入
这类错误本质是容器解析失败，最常见于控制器构造函数或方法注入时，类型提示的类名写错、命名空间漏了 \，或者服务提供者没注册。
- 错误信息里出现
Too few arguments to function App\Http\Controllers\Api\UserController::__construct()，说明容器找不到某个依赖的实例，比如你写了SomeService $service，但没在app/Providers/AppServiceProvider.php的register()里绑定它 -
Call to a member function xxx() on null往往是注入的依赖为null，典型场景：用了private $repo;但忘了在__construct()里赋值，或类型提示写成了接口却没绑定实现 - 运行
php artisan tinker，手动执行app()->make(YourClass::class)，能快速验证容器是否能解析该类
日志没报错但还是500？检查响应内容和 Content-Type
极少数情况下，500 来自响应体非法，比如控制器返回了非 JSON 内容（如 echo 了调试字符串），而前端强设了 Accept: application/json，Laravel 的异常处理器会因无法序列化响应而 fallback 到 500。
- 用
curl -v http://your-api/xxx看完整响应头和体，确认返回的是合法 JSON（开头是{或[），而不是 HTML 错误页或裸文本 - 检查控制器是否混用了
return response()->json(...)和echo "debug"—— 后者会污染输出缓冲，JSON 编码失败 - 如果用了自定义异常渲染（
App\Exceptions\Handler::render），确保所有分支最终都返回Response实例，不要漏掉parent::render()或返回了字符串
真正卡住的往往不是错误本身，而是日志被权限挡住、APP_DEBUG 关着、或错误发生在日志写入之前（比如引导阶段的配置解析失败）。先让 laravel.log 可写，再开 APP_DEBUG，剩下的基本都能在日志第一行看到。
