发布于2026-07-06 阅读(0)
扫一扫,手机访问
处理异常这件事,说简单也简单,说复杂确实有不少门道。很多刚接触 Lara vel 的开发者,一遇到错误页面就以为是自己代码写得有问题,其实大部分时候只是异常处理链路没有摸清楚。

先聊一个基本事实:所有没被 try/catch 拿住的异常,最终都会掉进 App\Exceptions\Handler 的 render() 方法。Lara vel 会看异常类型、请求是不是 AJAX、以及当前是不是调试模式,来决定返回一段 JSON 还是渲染一个视图页面。
关键就在这里:不是所有异常都会进 report(),但所有异常一定会在 render() 里走一遭——这是你控制响应内容的唯一入口,千万别忽略。
APP_DEBUG=true)下,直接甩出 Whoops 错误页,根本不会走你自定义的视图APP_DEBUG=false)下,render() 才会生效,返回你配好的错误页面HttpException(比如 404、500)会被自动映射到 resources/views/errors/404.blade.php 这类路径——前提是文件存在且命名规范不用改路由,也不用写中间件。Lara vel 会自己去找 resources/views/errors 下对应状态码的 Blade 文件,比如 404.blade.php、500.blade.php、419.blade.php。
但有个细节要注意:文件名必须是纯数字加 .blade.php,不能带下划线,也不能搞大小写——Lara vel 不会 fallback 到 5xx.blade.php 这种通配名。
APP_DEBUG=false,否则永远看不到这些页面$exception 变量(仅限 4xx/5xx 视图),但别在上面输出敏感信息__() 或 @lang——翻译服务可能已经不可用了有些业务异常,比如 OrderNotFoundException,你希望它返回 404 页面,而不是默认的 500。这时候就得在 App\Exceptions\Handler@render 里手动干预了。
别直接 throw 一个新异常,也别试图改一下响应头就 return——Lara vel 要求你 return 一个 Response 实例或者字符串。
render() 里用 instanceof 判断异常类型response()->view('errors.custom-order', [], 404) 显式返回视图response()->json(['message' => '...'], 404)report() 里对这类异常做日志或告警——render() 不负责记录说起来,自定义页面不生效,十有八九不是代码写错了,而是环境或路径没对上。
APP_DEBUG=true 时死活不显示自定义页——这是设计行为,不是 bugerrors/404.php(漏了 .blade)或 Errors/404.blade.php(大小写敏感,Linux 服务器上会 404)php artisan view:clear,尤其改过 Blade 之后render() 里写了 dd() 或抛了新异常,流程直接中断,根本没走到返回逻辑稍微复杂一点的地方在于:异常处理链路横跨 HTTP 生命周期、队列、命令行三种上下文。而 Handler 类只管 HTTP 请求。队列任务里的异常不会进这里,得单独处理。这一点在架构设计时就要想清楚,别等到线上出了问题才回头排查。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8