中间件异常未进全局处理器是因为未继承HttpResponseException或未被Handler捕获；应抛出其子类、避免命名冲突、检查$dontReport配置，或直接return响应。
中间件里抛出的异常为什么没进全局异常处理器
因为 Laravel 的中间件执行链在请求进入控制器前就结束了，如果中间件里 throw 一个异常，它确实会冒泡上去，但**只有被框架“识别为 HTTP 异常”的才会走 App\Exceptions\Handler::render()**。普通 Exception 或自定义异常类若没继承 Illuminate\Http\Exceptions\HttpResponseException 或没被 Handler 显式捕获，就会直接报错白屏或返回 500，且不触发你写的日志、响应格式化逻辑。
- 常见错误现象：
Class 'App\Exceptions\CustomMiddlewareException' does not exist（没自动加载），或异常进了 PHP 错误日志但没进你的storage/logs/laravel.log - 正确做法：在中间件中抛出的异常，必须是
Illuminate\Http\Exceptions\HttpResponseException子类，或确保它被app/Exceptions/Handler.php的render()方法覆盖 - 更稳妥的写法不是“抛异常”，而是提前返回响应：
return response()->json(['message' => '权限不足'], 403);—— 这完全绕过异常机制，也最可控
Laravel 10+ 中间件异常捕获要检查 $dontReport 配置
即使你写了 try/catch 并手动调用 report()，某些异常仍不会记录到日志，原因很可能是它们落在了 app/Exceptions/Handler.php 的 $dontReport 数组里。Laravel 默认把 Illuminate\Session\TokenMismatchException、Illuminate\Validation\ValidationException 等加进去了，而你自己写的中间件异常如果类型匹配（比如也叫 ValidationException），也会被跳过。
- 检查点：打开
app/Exceptions/Handler.php，确认$dontReport是否包含你中间件抛出的异常类名 - 如果要用自定义异常，别复用框架已有类名；命名建议带前缀，如
MiddlewareAuthException - 临时调试可注释掉
$dontReport数组，看异常是否开始进日志 —— 别在线上这么干，仅用于定位
中间件里 try/catch 后该不该 throw？
取决于你想要的控制流。直接 throw 新异常会让它重新进入异常处理流程；而 return 响应则彻底中断中间件链。多数情况下，后者更干净。
- 用
return：适合业务拦截场景，比如权限校验失败返回 403，不需要堆栈、不希望触发报警系统 - 用
throw：适合需要统一监控/告警的底层问题，比如 Redis 连接失败、配置缺失，这时应抛出明确异常类，并在Handler::render()里统一转成 500 响应 + 上报 - 别在
catch里静默吞掉异常（即既不return也不throw），这会导致请求卡住或返回空响应，极难排查
API 路由中间件异常返回 JSON 还是 HTML？
默认 Laravel 不区分中间件来源，Handler::render() 返回的响应类型由请求头 Accept 决定。但中间件运行时，Accept 可能是 text/html（浏览器直访）或 application/json（前端 AJAX），而你中间件的错误响应应该跟接口风格一致。
- 简单判断方式：
if ($request->expectsJson()) { return response()->json(...); } - 更健壮的做法：在中间件里统一用
response()->json()，而不是依赖Handler自动转换 —— 因为中间件早于控制器，expectsJson()可能不准（比如 POST 表单没带 header） - 注意：如果用了
api中间件组（如throttle:api），Laravel 会自动设Accept: application/json，但自定义中间件不享受这个待遇，得自己判断
