应使用语义化异常类而非throw new Exception，自定义异常需实现render()方法区分JSON/HTML响应，验证用$request->validate()，异常类加入$dontReport可静默忽略日志。
控制器里直接 throw 新异常太粗糙
很多新手会在控制器里写 throw new Exception('xxx') 或者 throw new RuntimeException('xxx')，这会导致异常被 Handler::render() 按默认逻辑处理 —— 开发环境显示堆栈，生产环境返回 500 页面，且无法区分业务语义。更糟的是，这类原始异常不会自动进入 $dontReport 白名单，可能把无关错误刷爆日志。
真正该做的，是让异常自带上下文和响应意图：
- 用 Laravel 已有的语义化异常类，比如
AuthenticationException、AuthorizationException、ModelNotFoundException，它们会被框架自动转成对应 HTTP 状态码（401/403/404） - 业务逻辑错误优先抛出自定义异常类（如
InvalidRequestException），而不是通用Exception - 避免在控制器里写
try/catch包裹整个方法体 —— 这会掩盖异常源头，也违背 Laravel 的异常流设计
自定义异常类必须实现 render() 方法
你创建的 app/Exceptions/InvalidRequestException.php 如果不重写 render()，它就只是个普通异常，框架不会知道该怎么响应用户。Laravel 的 Handler::render() 只有在明确匹配到该类实例时，才会调用其 render()。
典型写法：
public function render($request)
{
if ($request->expectsJson()) {
return response()->json(['message' => $this->getMessage()], 422);
}
return redirect()->back()->withErrors(['message' => $this->getMessage()]);
}
注意两点：
-
$request->expectsJson()判断依据是请求头含X-Requested-With: XMLHttpRequest或 Accept 包含application/json，不是靠 URL 后缀或路由名 - 别在
render()里再抛异常 —— 它本身就在异常处理链中，二次抛出会触发 fatal error
不要在控制器里手动调用 report() 或写日志
有人为了“保险”会在控制器里加 Log::error() 或 report($e)，这是重复劳动。Laravel 的 Handler::report() 默认会对所有未被 $dontReport 过滤的异常自动记录到 storage/logs/laravel.log。
正确做法是把需要静默忽略的日志类异常加进 $dontReport：
protected $dontReport = [
\Illuminate\Auth\AuthenticationException::class,
\App\Exceptions\InvalidRequestException::class,
];
这样既减少日志噪音，又保留了异常的业务响应能力 —— render() 仍会执行，只是不落盘。
表单验证失败别自己 throw 异常
用 $request->validate() 或 Validator::make() + ->validate() 就够了。Laravel 会自动抛出 ValidationException，它已内置适配：expectsJson() 时返回 422 JSON，否则重定向并绑定 $errors。
手写验证逻辑再 throw 是反模式，除非你有特殊字段映射或动态规则需求。此时也建议封装进 Request 类，而非塞在控制器里。
最易被忽略的一点：ValidationException 的 errors 键名默认是字段名，但前端如果用驼峰命名（如 userEmail），而验证规则里写的是 'user_email' => 'required|email'，那 JSON 响应里的错误 key 就是 user_email，前端需对齐 —— 这类不一致问题往往在线上才暴露。
