DB::transaction闭包是最稳妥的手动事务控制方式，它自动处理提交回滚、支持嵌套降级、确保连接状态清理、可配置超时，并要求闭包内仅执行数据库操作且通过throw抛异常。
直接用 DB::transaction 闭包是最稳妥的手动事务控制方式，它自动处理提交与回滚，且支持嵌套事务的降级处理。
为什么不能只靠 try-catch 自己调 DB::commit() 和 DB::rollback()
手动配对调用容易出错：比如忘记在 catch 中 rollback、异常未被捕获、或事务中途被其他逻辑意外中断。更关键的是，Laravel 的底层 PDO 连接在 rollback 后若未重置状态，后续查询可能报 SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active 这类隐晦错误。
-
DB::transaction内部用try/finally确保无论是否抛异常，连接状态都被正确清理 - 它还会检测是否已处于事务中——若已开启，会转为 savepoint 模式，避免嵌套事务失败
- 超时时间可配置，默认 60 秒，超时会强制 rollback 并抛
Illuminate\Database\TransactionException
DB::transaction 闭包里写什么才安全？
闭包内只能执行数据库操作，不要混入 HTTP 请求、文件写入、队列分发等外部副作用。一旦这些操作失败，事务无法回滚它们，造成数据不一致。
- 所有 Eloquent 操作（
save()、delete()、update()）和原生查询（DB::insert()、DB::table()->where()->update()）都受事务保护 - 避免在闭包里调
DB::transaction嵌套——虽然 Laravel 支持，但深度嵌套会让调试和锁等待变得难以追踪 - 不要在闭包中 return 非数据库结果（如 API 响应数组），因为返回值会被忽略；需把结果提前赋值给闭包外变量
常见错误：闭包里抛了异常但没被事务捕获？
最常踩的坑是用了 throw_if()、abort_if() 或自定义异常但没注意异常类型——DB::transaction 只会在 Throwable 被抛出时触发 rollback，而某些校验函数默认 throw Exception，这没问题；但如果你用 return response()->json(...) + exit 这种老式终止方式，事务根本不会回滚。
- 确保所有中断逻辑都通过
throw发出异常，而不是die、exit或静默返回 - 验证类（如
Validator::validate()）抛的ValidationException是Throwable子类，能被正常捕获 - 如果必须做条件判断后中断，写成：
if ($condition) { throw new RuntimeException('业务规则不满足'); }
性能与兼容性要注意什么？
事务越长，锁持有时间越久，高并发下容易触发死锁或超时。MySQL 默认隔离级别是 REPEATABLE READ，Laravel 不会帮你改；PostgreSQL 则默认 READ COMMITTED。不同引擎行为差异大：
- InnoDB 支持行锁，但
SELECT ... FOR UPDATE在无索引字段上会升级为表锁 - SQLite 不支持真正的并发事务，
DB::transaction在 SQLite 上只是模拟，不适合生产环境多写场景 - 长时间运行的事务（>30s）建议拆成小事务，或用
DB::transaction(..., $timeout)显式设低超时值防堆积
真正难的是权衡一致性与响应速度——比如一个订单创建要扣库存、记流水、发通知，前三步必须原子，最后一步失败不能让订单回滚，得单独设计补偿逻辑。这时候事务边界就得切在“扣库存+记流水”之后，而不是包揽全部。
