QueryException 必须显式捕获或交由全局 Handler 处理，不能依赖框架自动转成500页面；其默认不触发友好错误页，需在 render() 中按错误码（如1062→409、1452→400）返回对应 JSON 响应，并手动展开 getPrevious() 获取底层信息，同时过滤敏感字段、确保事务回滚及线上日志覆盖。
数据库异常必须显式捕获或交由全局 Handler 处理，不能依赖框架自动转成 500 页面——QueryException 默认不触发 Laravel 的友好错误页，直接暴露白屏或不完整 JSON。
QueryException 为什么总被当成 500 上报？
MySQL 的 1062 Duplicate entry、1452 Cannot add or update a child row 这类错误，Laravel 包装成 QueryException 后，底层原始信息藏在 $exception->getPrevious() 里。直接记录 $exception->getMessage() 只会写 “SQLSTATE[23000]: Integrity constraint violation”，查不到具体字段和值。
- 日志中必须手动展开：用
$exception->getPrevious()?->getMessage()拿到底层 PDO 报错 - 敏感字段（如密码、token、手机号）不能出现在日志里，哪怕在本地调试也要过滤
-
DB::enableQueryLog()仅限本地开启，线上环境必须关闭
API 接口里怎么把 QueryException 转成 400/409？
用户提交重复邮箱、删除被关联的分类——这些不是服务器错误，而是客户端可修正的业务问题，不该返回 500。Handler 的 render() 方法里要针对性拦截：
- 先用
$request->expectsJson()判断是否为 API 请求 - 对
$exception instanceof QueryException，再用$exception->errorInfo[1]或正则匹配错误码（如/1062/）区分类型 - 1062 → 返回 409 Conflict +
["message" => "Email already exists"] - 1452 → 返回 400 Bad Request +
["message" => "Cannot delete category with associated products"] - 其他未识别 SQL 错误才 fallback 到 500
事务里抛出 QueryException 会自动回滚吗？
会，但前提是异常没被事务闭包内部吞掉。Laravel 的 DB::transaction() 只响应「未被捕获的 Throwable」。
- 下面这段代码 不会回滚：
DB::transaction(function () { DB::table('users')->insert([...]); try { DB::table('logs')->insert([...]); // 触发 QueryException } catch (QueryException $e) { Log::error($e->getMessage()); // 吞掉异常，事务认为成功 } }); - 正确做法是捕获后立刻重抛：
throw $e;，或干脆不 catch，让异常冒泡 - 注意：MyISAM 表引擎不支持事务，换 InnoDB 是前提
为什么本地能看到 SQL 错误，线上却只显示“Server Error”？
因为线上 APP_DEBUG=false，且默认 Handler@render() 对 QueryException 没做特殊处理，直接走父类逻辑——最终调用 convertExceptionToResponse()，返回空白 500 响应。
- 别指望开发环境能覆盖线上行为；所有数据库异常路径必须在
render()和report()中显式覆盖 - 测试时务必关掉
APP_DEBUG，用curl -H "Accept: application/json"模拟真实 API 调用 - 忽略
shouldReport()的返回值会导致日志缺失，尤其是想监控 1062 出现频次时
