17370845950

Laravel通过App\Exceptions\Handler类实现分层异常处理：report()记录日志，render()返回响应；自定义异常需继承Exception并在render()中匹配处理，避免中间件内catch破坏生命周期。

PHP 主流架构（如 Laravel、Symfony、ThinkPHP）不依赖 try/catch 全局兜底，而是通过异常处理器 + 中间件/事件监听组合实现分层捕获——全局兜得住，局部控得细。

全局异常处理器怎么注册（以 Laravel 为例）

Laravel 的 App\Exceptions\Handler 类是核心入口，所有未被 try/catch 拦截的异常最终都会走到 render() 方法。它不是“自动生效”，而是由框架在启动时通过 Illuminate\Foundation\Http\Kernel 绑定到 Illuminate\Contracts\Debug\ExceptionHandler 接口。

• report() 用于日志记录或上报（如 Sentry），不返回响应，可在此过滤敏感信息
• render() 必须返回 Response 实例，决定用户看到什么（JSON 错误结构 or 视图页面）
• 不要在 render() 里写 die 或 exit，会绕过响应生命周期，导致中间件、事件失效
• 自定义异常类需继承 Exception，并可在 $dontReport 数组中排除不需记录的类型（如 ValidationException）

局部捕获什么时候该用 try/catch

局部捕获只在业务逻辑明确知道「某段代码可能失败，且有替代路径」时才用，不是为了“防止崩溃”。主流架构中滥用 try/catch 反而会掩盖真实问题。

• 调用第三方 API（如支付回调验签失败、HTTP 请求超时）——失败后可降级或重试
• 文件操作（fopen、file_put_contents）——失败后可切备用存储或抛出业务异常
• 数据库唯一约束冲突（IntegrityConstraintViolationException）——转为用户友好的提示，而非堆栈
• 避免包裹整个控制器方法：Laravel 的 validate() 已自动抛出 ValidationException，再套一层 try 属于冗余

如何让自定义异常走统一渲染流程

关键不是 throw 新异常，而是确保它被框架识别为“可处理异常”。直接 throw new Exception('xxx') 会被当成底层错误，丢失上下文；应使用继承链 + 异常映射。

• 定义业务异常类，如 App\Exceptions\OrderAlreadyPaidException，继承 Exception
• 在 app/Exceptions/Handler.php 的 render() 中判断类型：

  if ($exception instanceof OrderAlreadyPaidException) {
      return response()->json(['message' => '订单已支付'], 400);
  }

• 更规范的做法是配合 Illuminate\Foundation\Exceptions\Handler::register()（Laravel 9+）或在 render() 开头用 is_a() 判断，避免硬编码 if 链
• 注意：PHP 8.0+ 支持 throw new Exception('msg', 400)，但状态码不会自动透传到响应，仍需在 render() 中显式提取

中间件里捕获异常容易踩的坑

中间件不是异常捕获的主战场。试图在中间件里用 try/catch 包裹 $next($request) 并返回响应，会破坏请求生命周期——比如 session 不保存、事件不触发、响应中间件（如 CORS）被跳过。

• 真正适合中间件处理的是「请求前校验类异常」，如 token 过期、权限不足，此时还没进路由，可安全拦截
• 若必须处理下游异常（如控制器抛出），应在 render() 中统一做，而不是在中间件里 catch 后手动构造 Response
• 某些日志中间件会尝试 catch 然后 report，但必须紧接着 throw $e，否则异常消失，后续处理器收不到
• 异步任务（如队列 Job）需单独配置 failed() 方法，和 HTTP 请求的异常处理完全隔离

异常处理的复杂点不在语法，而在分层职责：底层异常暴露细节，中间层做转换与决策，上层只负责呈现。漏掉任意一层，要么日志里全是裸堆栈，要么用户看到“500 Internal Server Error”却不知所措。