db::transaction 仅在匿名函数抛出未捕获异常时自动回滚，依赖php异常机制而非sql错误码；需启用pdo::errmode_exception，避免吞异常、嵌套事务及阻塞i/o。
DB::transaction 会自动回滚吗
会，但只在匿名函数里抛出未捕获的异常时触发。它不是“监听错误码”或“检测 SQL 失败”，而是依赖 PHP 异常传播机制。一旦你在事务闭包里 throw new Exception() 或调用了一个会抛异常的方法（比如模型验证失败、saveOrFail() 写入失败），Laravel 就会执行 ROLLBACK。
常见误区：
– 认为 SQL 报错（如外键冲突）会自动被捕捉并回滚 → 实际上如果没开启 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，PDO 默认静默失败，事务不会中断，也不会回滚
– 在闭包里用 return false 或 dd() 中断流程 → 不触发回滚，事务仍处于打开状态，可能造成连接卡住或数据不一致
- 确保数据库配置中已启用异常模式：
'options' => [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION] - 不要用
try/catch在闭包内吞掉异常，除非你明确要自己处理并手动throw或DB::rollBack() - 避免在事务中调用外部 HTTP 请求、文件写入等不可回滚操作 —— 它们成功了，但 DB 回滚了，业务就错位了
嵌套事务为什么不起作用
Laravel 的 DB::transaction() 不支持真正的嵌套事务。第二次调用只是增加一个嵌套计数器，底层仍是单层 BEGIN，回滚时也只会退到最外层的起点。
典型现象：
– 外层事务抛异常 → 全部回滚
– 内层事务抛异常，但外层 catch 住了 → 内层变更实际已提交（因为没真正 BEGIN）
- PHP 层面的“嵌套”只是语法糖，MySQL 等多数数据库本身不支持 SAVEPOINT 自动管理（除非你显式用
DB::transaction(function () { ... }, $attempts)并配合DB::beginTransaction()+DB::rollbackTo()） - 若需局部回滚逻辑，改用
DB::beginTransaction()+DB::rollBackTo('savepoint_name')显式控制，但要注意 Laravel 默认不帮你建 savepoint - 更稳妥的做法是拆分逻辑：把可能失败的子操作提前校验，或用独立事务 + 补偿操作（比如发消息通知后续清理）
事务超时或连接中断怎么办
事务长时间不结束（比如卡在 API 调用、循环处理大数据），会导致连接占用、锁表、甚至被 MySQL 的 wait_timeout 或 innodb_lock_wait_timeout 强制断开，此时 Laravel 不会自动感知连接失效，DB::commit() 可能静默失败或抛出 PDO 连接异常。
