关键是要让错误暴露出来：设APP_DEBUG=true、查laravel.log日志、用Postman绕过前端干扰、检查VerifyCsrfToken和EnsureFrontendRequestsAreStateful中间件是否误拦截，再在控制器加dd()定位问题环节。
想看清 Laravel POST 接口返回的错误信息，关键不是“看”，而是让错误真正暴露出来——默认情况下，Laravel 在生产环境会隐藏详细错误，只返回通用 500 或空白响应；开发环境下若仍看不清，说明错误没走到 PHP 层，或被中间件/框架提前拦截了。
打开调试模式并检查日志文件
确保 .env 中设置 APP_DEBUG=true 且 APP_ENV=local。这样触发异常时，浏览器会显示完整的堆栈、类名、行号和变量快照。同时查看 storage/logs/laravel.log，它记录每次请求的完整上下文，包括请求参数、中间件执行顺序和抛出的异常类（比如 TokenMismatchException 或 MassAssignmentException）。日志里出现 Method Illuminate\Http\Request::show does not exist 这类提示，说明是路由方法名写错或控制器缺失；出现 Call to a member function ... on string 则大概率是模型绑定失败，传入的是字符串而非模型实例。
用 Postman 或 curl 绕过前端干扰
浏览器发起的 POST 请求常带 CSRF 头、Referer、Cookie 等额外因素，容易掩盖真实问题。直接用 Postman 或命令行 curl 发起干净请求：
- 去掉所有自定义 header（尤其 X-CSRF-TOKEN、X-Requested-With）
- body 选 raw → JSON，手动输入合法 JSON，避免前端序列化错误
- curl 示例：
curl -X POST http://localhost:8000/api/login -H "Content-Type: application/json" -d '{"email":"test@example.com","password":"123"}'
如果此时返回清晰的 JSON 错误（如 {"message":"Unauthenticated."} 或 {"message":"The given data was invalid.","errors":{"email":["The email field is required."]}}），说明问题出在前端 token、header 或数据格式；如果仍是 500 且无详情，就一定是后端逻辑崩溃，需查日志。
检查中间件是否静默拦截
Laravel 很多错误其实根本没进控制器，而是在中间件阶段就被拦下了：
-
VerifyCsrfToken拦截会返回 419（页面已过期），但不写日志——检查app/Http/Middleware/VerifyCsrfToken.php的$except数组是否漏加 API 路由 -
EnsureFrontendRequestsAreStateful在 API 路由中检测到 Origin 头，会强行启用 session 和 CSRF 校验，导致纯 API 请求失败——确认你是否真需要 Sanctum 的 SPA 认证，不需要就从api中间件组中移除它 -
ThrottleRequests触发限流时返回 429，但默认不记录日志，需主动在app/Exceptions/Handler.php中捕获并写入
在控制器里加临时调试输出
如果日志和 Postman 都没线索，就在控制器入口处加最简调试：
- 第一行写
info('POST request received', $request->all());—— 如果这行没出现在日志里，说明请求连控制器都没进，问题在路由或中间件 - 在模型操作前加
dd($request->validated());或dump($request->all());，确认数据结构是否符合预期（比如 Amadeus 接口要求json选项，但你用了body，Guzzle 就不会自动序列化） - 对模型赋值前检查字段：
info('fillable fields:', (new Post)->getFillable());，避免因$fillable漏配导致静默失败
不复杂但容易忽略
