Laravel中间件异常未被全局处理器捕获，因中间件在路由匹配前执行，其抛出的异常会跳过Handler直接冒泡；需确保异常继承Exception并在Handler::render()中显式处理，或改用abort()、HttpResponseException等Laravel标准方式。
中间件里抛出的异常为什么没被全局异常处理器捕获
因为 Laravel 的中间件执行链在请求进入路由之前就已启动，而 App\Exceptions\Handler 默认只接管「路由匹配成功后」抛出的异常。中间件里直接 throw 的异常，如果发生在 handle() 中且未被 try-catch，会跳过路由层，直接冒泡到 HTTP 内核外，导致 500 页面但日志里可能没记录，或记录为 Symfony\Component\HttpKernel\Exception\HttpException 等包装异常。
- 检查你的中间件是否在
app/Http/Kernel.php的$middleware（全局）或$middlewareGroups（分组）中注册 —— 只有这里注册的中间件才走标准异常流程 - 避免在中间件里写裸
throw new Exception(...)，优先用 Laravel 提供的异常类，比如abort(403)或throw new AuthorizationException()，它们会被Handler正确识别 - 若必须抛自定义异常，确保它继承
Exception，并在app/Exceptions/Handler.php的render()方法里显式处理，例如：if ($exception instanceof MyCustomMiddlewareException) { return response()->json(['error' => 'Access denied'], 401); }
Laravel 10+ 中间件异常被吞掉的常见原因
升级到 Laravel 10 或更高版本后，Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull 等内置中间件默认启用，某些异常（如 JSON 解析失败、空字符串转 null 时类型不匹配）会在更早阶段被静默忽略或转成 400，而不是抛出可捕获的异常。
- 检查
app/Http/Kernel.php中是否启用了TrimStrings、ConvertEmptyStringsToNull等中间件；临时注释它们，确认异常是否重现 - 用
dd()或Log::debug()在中间件handle()开头打点，确认代码是否真的执行到了抛异常的位置 —— 很多时候是前置中间件已返回响应，后续中间件根本没运行 - 注意
return $next($request)前后的逻辑顺序：一旦你提前return response()，后面代码不会执行，异常也不会抛出
如何让中间件异常统一走 API 响应格式
当项目同时支持 Web 和 API 路由时，中间件里抛的异常默认走 HTML 响应（比如 500.blade.php），但 API 客户端需要 JSON。不能靠全局 Accept: application/json 自动判断，得在中间件内部主动控制。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 在中间件中判断请求类型：
if ($request->expectsJson()) { throw new HttpResponseException(response()->json(['message' => 'Forbidden'], 403)); } - 不要依赖
abort()直接返回 JSON —— 它仍可能被Handler渲染成视图，除非你在Handler.php里重写了render()对HttpException的处理 - 更稳妥的做法是：中间件里不抛异常，而是返回标准化响应，比如
return response()->json(..., 401)，把“异常语义”转为“响应语义”，彻底绕过异常处理链
测试中间件异常捕获是否生效
光看浏览器 500 页面没用，得验证异常是否真进了 Handler::render()，以及日志是否写入、响应格式是否符合预期。
- 在
app/Exceptions/Handler.php的render()开头加一行Log::info('Exception caught in Handler', ['class' => get_class($exception)]);，然后触发中间件异常，查日志确认是否命中 - 用 PHPUnit 写一个中间件测试，模拟请求并断言响应状态码和内容：
$response = $this->get('/protected-route') ->assertStatus(403) ->assertJson(['message' => 'Forbidden']); - 注意：Tinker 或 Artisan 命令中调用中间件（比如在命令里手动 new + handle）不会触发 HTTP 异常流程，那只是普通 PHP 异常，需单独 try-catch
中间件异常捕获最易被忽略的一点：它高度依赖执行时机和注册位置。同一个异常，在路由闭包里抛是标准流程，在全局中间件里抛可能被内核截断，在中间件构造函数里抛则根本不会被捕获 —— 因为 handle() 都没机会执行。
