Laravel异常处理由App\Exceptions\Handler类统一管理，核心是report()方法记录异常、render()方法返回响应；需按请求类型（网页/API）和异常语义定制逻辑，避免生产环境开启调试模式。
在 Laravel 中，异常和错误统一由 App\Exceptions\Handler 类处理，它负责记录、渲染和响应各类异常。核心逻辑集中在 render() 和 report() 两个方法上，自定义时无需重写整个流程，只需按需覆盖即可。
report() 方法：记录异常到日志或第三方服务
该方法用于“上报”异常，比如写入日志、发送告警、同步到 Sentry 等。Laravel 默认已调用 Log::error() 记录所有未捕获异常。
常见扩展方式：
- 对特定业务异常（如
OrderException）额外触发企业微信/钉钉通知 - 忽略某些预期异常（如
ValidationException），避免刷屏日志 - 补充上下文信息（用户 ID、请求 URL、IP）便于排查
示例：
public function report(Throwable $throwable): void
{
if ($throwable instanceof CustomBusinessException) {
\Log::warning('业务异常', [
'message' => $throwable->getMessage(),
'user_id' => auth()->id(),
'url' => request()->fullUrl(),
]);
// 可选：发通知
notifyAdmin("⚠️ 业务异常：{$throwable->getMessage()}");
}
parent::report($throwable);
}
render() 方法：决定如何向用户返回响应
该方法决定异常“怎么展示”，返回一个 Response 实例。Laravel 默认对 HTTP 异常（如 404、500）返回视图，对 API 请求返回 JSON。
关键点：
- 通过
$request->expectsJson()判断是网页还是 API 请求 - 可针对不同异常类型返回定制化响应（如模型未找到时返回 404 JSON）
- 不建议在 render 中抛出新异常，否则可能陷入递归
示例：
public function render($request, Throwable $throwable): Response|ResponseFactory
{
if ($throwable instanceof ModelNotFoundException && $request->expectsJson()) {
return response()->json([
'message' => '资源不存在',
'error' => 'not_found',
], 404);
}
if ($throwable instanceof ValidationException && $request->expectsJson()) {
return response()->json([
'message' => '验证失败',
'errors' => $throwable->errors(),
], 422);
}
return parent::render($request, $throwable);
}
自定义异常类 + 注册到 $dontReport
对于明确属于“预期内”的异常（如表单验证失败、权限不足），可继承 Exception 创建语义化类，并选择性屏蔽日志记录，避免干扰真实问题。
操作步骤：
- 新建
app/Exceptions/PermissionDeniedException.php - 在
app/Exceptions/Handler.php的$dontReport数组中加入该类 - 在
render()中单独处理其响应格式
这样既保持代码可读性，又让日志更聚焦于真正需要关注的错误。
调试模式与生产环境的区别
APP_DEBUG=true 时，Laravel 显示带堆栈的详细错误页（Whoops）；APP_DEBUG=false 时，统一返回通用 500 页面（或你配置的 resources/views/errors/500.blade.php）。
注意：
- 不要在生产环境开启 debug，会暴露路径、配置、数据库结构等敏感信息
- API 接口即使 debug 关闭，也会默认返回简洁 JSON 错误（除非你重写了 render）
- 自定义错误页面放在
resources/views/errors/xxx.blade.php，支持 404、403、500 等状态码命名
基本上就这些。Handler 不复杂但容易忽略细节，关键是分清 report（记下来）和 render（给出去）的职责，再结合请求类型和异常语义做轻量定制。
