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') 会被当成底层错误，丢失上下文；应使用继承链 + 异常映射。
立即学习“PHP免费学习笔记（深入）”；
- 定义业务异常类，如
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”却不知所措。
