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 连接异常。
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
- 在事务闭包开头加超时控制：
set_time_limit(30)，或用microtime(true)手动检查耗时 - 避免在事务中做任何阻塞型 I/O（cURL、Redis 查询、文件读写）
- 生产环境务必配置数据库的
wait_timeout（建议 ≥60 秒）和应用层连接池空闲回收策略，防止事务中途失联 - 如果必须异步，把耗时操作移出事务，用队列 + 状态字段（如
is_processing）+ 最终一致性保证
DB::transaction 和模型事件的交互风险
模型的 creating、saving、created 等事件在事务内触发，但如果你在事件监听器里又开了新事务、查了其他库、或调用了非事务安全的方法（如缓存 Cache::put()），就可能破坏原子性。
- 事件监听器默认共享当前事务连接，但缓存、日志、通知等副作用操作不应依赖事务成败 —— 它们无法回滚
- 避免在
saved或updated事件里调用DB::transaction()，容易引发连接嵌套混乱或死锁 - 如需在事务后触发可靠动作，改用
DB::afterCommit()（Laravel 9+），它会在 commit 成功后延迟执行回调，且自动绑定当前连接生命周期
事务真正难的不是语法，是判断哪些操作能放进同一个原子单元、哪些必须解耦、以及连接和异常如何对齐。很多线上数据不一致问题，都出在以为“包一层 transaction 就万事大吉”上。
