Laravel 8–11事务回调依赖数据库事件系统，无原生onCommit/onRollback钩子；成功用DB::afterCommit()（9+引入），失败统一触发TransactionFailed事件，显式事务才支持监听，DB::transaction闭包内事件不可用。
从 Laravel 8 到 11，事务执行成功与失败的回调机制在事件粒度、触发时机和可靠性上逐步明确，但核心逻辑未变：框架不提供“钩子函数”式 API（如 onCommit() 或 onRollback()），而是依赖数据库事件系统实现解耦监听。
事务成功后执行逻辑：DB::afterCommit() 成为标准方式
Laravel 9 起正式引入 DB::afterCommit()，并在 10–11 中稳定强化。它不是“钩子函数”，而是一个延迟注册器：仅当当前连接处于事务中且最终提交成功时，闭包才被执行。
- 适用于发送通知、分发队列任务、清理缓存等需强一致性保障的操作
- 若事务被回滚（无论主动
rollback()还是异常中断），闭包完全不会运行 - 不支持嵌套事务内的独立触发——外层事务提交才触发所有已注册的
afterCommit闭包 - 旧版（Laravel 8）无此方法，需手动暂存任务 + 在
commit()后显式分发
事务失败时的捕获：TransactionFailed 事件统一覆盖异常与回滚
Laravel 8+ 原生触发 Illuminate\Database\Events\TransactionFailed，该事件在事务因任何原因终止（包括 DB::rollback()、底层 PDO 异常、超时、死锁）后发出，是目前最通用的失败感知入口。
- 事件对象携带
$event->connection和$event->exception，可提取 SQL、绑定参数、PDO 错误码 - 不区分“主动回滚”和“被动崩溃”，如需区分，需业务层配合状态标记（例如设置
$manualRollback = true） - Laravel 8.x 在部分 MySQL 配置下可能漏发该事件；9+ 全驱动兼容性增强，11 中已稳定
- 不能在监听器内执行新数据库操作（易引发嵌套事务或连接失效）
事务开始与中间状态：TransactionBeginning 仅用于连接准备
TransactionBeginning 事件在 beginTransaction() 调用后、PDO 执行 BEGIN 前触发，此时事务计数器尚未更新（transactionLevel() 仍为 0）。
- 适合记录事务启动时间、绑定请求 ID、初始化上下文，但不可用于判断“事务已生效”
- 监听器中禁止调用
$connection->getPdo()—— 某些驱动（如 SQL Server）此时 PDO 实例尚未就绪 - 该事件在所有版本（8–11）中行为一致，无新增能力，但 11 对参数校验更严格（如拒绝非法连接名）
DB::transaction() 闭包内无法监听事务事件
这是跨版本共性限制：使用 DB::transaction(fn () => { ... }) 封装的逻辑，其内部不会触发 TransactionBeginning、TransactionCommitted 或 TransactionRolledBack 事件。
- 原因在于该封装绕过了事件广播路径，直接管理连接状态
- 若需监听，必须改用显式事务控制（
beginTransaction()/commit()/rollback()）并配合事件系统 - Laravel 11 并未修复或绕过该限制，文档也明确提示“闭包内事件不可用”
