Handler::render() 是唯一能覆盖所有 API 异常路径的方式，因其在框架内部捕获 ValidationException 等异常后直接调用，而中间件、控制器封装等均无法拦截；需结合 $request->is('api/*')、wantsJson() 和 ajax() 判断 API 请求，并扁平化验证错误、显式处理自定义异常。
直接改 App\Exceptions\Handler::render() 是唯一能覆盖所有 API 异常路径的方式，其他地方（中间件、控制器封装、响应宏）都漏掉验证失败、404、500 这些关键分支。
为什么中间件和控制器封装拦不住 ValidationException？
因为 Laravel 的 ValidationException 在控制器执行前就被 FormRequest 或自动验证逻辑抛出，根本没走到控制器或中间件的正常响应链。它被框架内部捕获后，直接交由 Handler::render() 处理——但默认实现对 JSON 请求没做格式隔离，结果就是 422 返回 HTML 表单错误页。
- 浏览器直接访问
/api/user（没带Accept: application/json）时，$request->expectsJson()返回false，即使路由在routes/api.php里也照样返回 HTML - 别依赖
FormRequest::failedValidation()重写来 throw 新响应——它只管验证失败，不管ModelNotFoundException或数据库异常 - 中间件里用
$response->setContent()强行包裹，会丢掉原始状态码（比如把 422 变成 200），前端收不到正确 HTTP 状态
render() 里怎么判断是 API 请求才走统一格式？
光靠 $request->expectsJson() 不够稳。开发时浏览器调试、Postman 默认头、某些 SDK 请求可能不带 Accept，但你又希望这些请求也走 JSON 格式。得加兜底逻辑：
- 优先检查
$request->is('api/*')—— 所有routes/api.php下的路由都匹配 - 再补上
$request->wantsJson()和$request->ajax()，覆盖老式 jQuery 请求 - 生产环境强制关闭
APP_DEBUG=true，否则500仍会返回 HTML 调试页，哪怕加了expectsJson()判断
示例判断逻辑：
if ($request->is('api/*') || $request->wantsJson() || $request->ajax()) { ... }
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
ValidationException 的 errors 怎么扁平化成前端要的结构？
默认 $exception->errors() 返回的是 ['email' => ['The email must be a valid email.']]，但前端习惯 [{'field': 'email', 'message': '...'}] 这种数组结构，字段名不能丢，因为表单要精准标红。
- 用
collect($exception->errors())->flatMap(function ($messages, $field) { return $messages->map(fn($m) => ['field' => $field, 'message' => $m]); })->values()->toArray() - 别用
array_values($exception->errors())—— 字段名丢失，定位不到哪个输入框出错 -
required_if这类规则可能导致一个字段多个错误，flatMap能保留全部，reset()只取第一个会丢信息
自定义异常（如 ApiException）为什么没生效？
手动 throw new ApiException('xxx') 后，如果没在 Handler::render() 里显式处理，它会被父类 parent::render() 拦下，最终返回空响应或 500 HTML 页——不是你定义的 code/message/data 结构。
- 必须在
render()开头加if ($exception instanceof ApiException)分支，且 return 自定义 JSON 响应 - 别忘了把
ApiException加进$dontReport数组，否则日志里堆满重复报错 - 第三方包（如 Stripe SDK）抛的异常若被业务层
try/catch吞掉又没throw，就彻底静默——这类地方得主动补throw new ApiException(...)
最易被忽略的点：Laravel 对 JSON 请求的异常处理完全绕过中间件和控制器逻辑，Handler::render() 是唯一可信入口；而 expectsJson() 的判定边界比直觉窄得多，必须用 is('api/*') 做硬匹配才能兜住所有情况。
